From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 439E6C433FE for ; Tue, 31 May 2022 22:42:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348384AbiEaWmC (ORCPT ); Tue, 31 May 2022 18:42:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346543AbiEaWmC (ORCPT ); Tue, 31 May 2022 18:42:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5584E2494D for ; Tue, 31 May 2022 15:42:01 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EE33E61455 for ; Tue, 31 May 2022 22:42:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 149FBC385A9; Tue, 31 May 2022 22:42:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654036920; bh=QhT5juI7EqHeP3aenNq6dvHIfW1V6Qz3IQeJ8sJg9Zg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=S6gSfnmB8s4nhVaNnn2qjxmmvOHBEk/bchmDwob+w+x79atN36h2tN6YarxsPtfgH lx+3FWXOXPlzM60hA5yhxct8K/AroyFY78egivH6t+xKCxcYZvpc8JDHdRAGU5Ob4k LSlDgX9m1BxdQlLIoP6QgzdSn5eKvwBnLvhn7SXBy4fWpJFTV/SqNflXq/YTrH2rTn Z48vfRkxyUfdNAPt3LwJ31m0Ggg2AzHpNX6KxGRpMVRjkK1VeKhflGAGYztO+0zUXg Z09N0NdxLEEl6U+bwQhvrNZk+tIgU+xCJXbv7Al2+jRd3w5EfTOr6VOCBoBWG1ErJh ynzula92tKGIw== Date: Tue, 31 May 2022 15:41:59 -0700 From: Jakub Kicinski To: Jiri Pirko Cc: Ido Schimmel , Ido Schimmel , netdev@vger.kernel.org, davem@davemloft.net, pabeni@redhat.com, jiri@nvidia.com, petrm@nvidia.com, dsahern@gmail.com, andrew@lunn.ch, mlxsw@nvidia.com Subject: Re: [PATCH net-next 00/11] mlxsw: extend line card model by devices and info Message-ID: <20220531154159.5dbf9d37@kernel.org> In-Reply-To: References: <20220527171038.52363749@kernel.org> <20220528120253.5200f80f@kernel.org> <20220530125408.3a9cb8ed@kernel.org> <20220531080555.29b6ec6b@kernel.org> <20220531090852.2b10c344@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 31 May 2022 21:34:42 +0200 Jiri Pirko wrote: > And again, for the record, I strongly believe that a separate dl > instance for this does not make any sense at all :/ I wonder why you > still think it does. For purely software reuse reasons. I think the line cards will require a lot of the same attributes as the full devlink instance, so making them a subobject which can have all the same attributes is poor SW arch. Think about it from OOP perspective, you'd definitely factor all that stuff out to an abstract class. We can't do that in netlink but whatever just make it a full dl instance and describe the link between the two. Most NIC vendors (everyone excluding Netronome?) decided that devlink instance is equivalent to a bus device which IIUC it was not supposed to be. It was supposed to be the whole ASIC. If we're okay to stretch the definition of a dl instance to be "any independently controllable unit of HW" for NICs then IDK why we can't make a line card a dl instance. Are you afraid of hiding dependencies?