From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Ido Schimmel <idosch@idosch.org>,
Ido Schimmel <idosch@nvidia.com>,
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
Date: Wed, 1 Jun 2022 09:35:04 +0200 [thread overview]
Message-ID: <YpcWqL5By3hU+AVP@nanopsycho> (raw)
In-Reply-To: <20220531154159.5dbf9d37@kernel.org>
Wed, Jun 01, 2022 at 12:41:59AM CEST, kuba@kernel.org wrote:
>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.
Sure, I understand the motivation.
>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
I agree, that is incorrect. That is why I was thinking about sort of
"alias" to make it right (2 PF devlink instances would be one connected
by alias). Not implemented yet though :/
>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.
Well, it is not independently controllable. Well, truth is, that in our
current implementation, there is one independent "configuration", and
that is flash burn of the gearbox. It is done using a "tunnelling"
register which encapsulates register communication what is done during
flash burning.
>
>Are you afraid of hiding dependencies?
Not really, I'm just not sure I see it is worth the excercise.
In czech, we have this saying: "kanon na vrabce". I think that the
following picture is better than any translation :)
https://i.iinfo.cz/images/72/shutterstock-com-kanon-delo-ptak-vrabec-strilet-1.jpg
Will think about it some more.
next prev parent reply other threads:[~2022-06-01 7:35 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-25 3:44 [PATCH net-next 00/11] mlxsw: extend line card model by devices and info Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 01/11] devlink: introduce line card devices support Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 02/11] devlink: introduce line card info get message Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 03/11] devlink: introduce line card device info infrastructure Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 04/11] mlxsw: reg: Extend MDDQ by device_info Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 05/11] mlxsw: core_linecards: Probe provisioned line cards for devices and attach them Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 06/11] selftests: mlxsw: Check devices on provisioned line card Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 07/11] mlxsw: core_linecards: Expose HW revision and INI version Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 08/11] selftests: mlxsw: Check line card info on provisioned line card Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 09/11] mlxsw: reg: Extend MDDQ device_info by FW version fields Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 10/11] mlxsw: core_linecards: Expose device FW version over device info Ido Schimmel
2022-04-25 3:44 ` [PATCH net-next 11/11] selftests: mlxsw: Check device info on activated line card Ido Schimmel
2022-04-25 9:50 ` [PATCH net-next 00/11] mlxsw: extend line card model by devices and info patchwork-bot+netdevbpf
2022-04-25 16:00 ` Jakub Kicinski
2022-04-25 19:39 ` Ido Schimmel
2022-04-25 19:52 ` Jakub Kicinski
2022-04-26 6:57 ` Jiri Pirko
2022-04-26 12:11 ` Andrew Lunn
2022-04-26 12:36 ` Jiri Pirko
2022-04-26 12:41 ` Jakub Kicinski
2022-04-26 14:00 ` Jiri Pirko
2022-04-26 14:51 ` Jakub Kicinski
2022-04-27 7:35 ` Jiri Pirko
2022-04-27 14:14 ` Jakub Kicinski
2022-04-29 11:51 ` Jiri Pirko
2022-04-29 18:45 ` Jakub Kicinski
2022-04-29 19:29 ` Jiri Pirko
2022-04-29 22:38 ` Jakub Kicinski
2022-04-30 6:27 ` Jiri Pirko
2022-05-02 14:39 ` Jakub Kicinski
2022-05-23 9:42 ` Jiri Pirko
2022-05-23 17:56 ` Jakub Kicinski
2022-05-24 6:46 ` Jiri Pirko
2022-05-24 14:31 ` Jiri Pirko
2022-05-24 18:00 ` Jakub Kicinski
2022-05-25 6:20 ` Jiri Pirko
2022-05-25 15:50 ` Jakub Kicinski
2022-05-26 9:05 ` Jiri Pirko
2022-05-26 10:47 ` Jiri Pirko
2022-05-26 11:45 ` Jiri Pirko
2022-05-26 17:35 ` Jakub Kicinski
2022-05-27 7:27 ` Jiri Pirko
2022-05-28 0:10 ` Jakub Kicinski
2022-05-28 9:09 ` Jiri Pirko
2022-05-28 19:02 ` Jakub Kicinski
2022-05-29 9:23 ` Jiri Pirko
2022-05-30 19:54 ` Jakub Kicinski
2022-05-31 7:11 ` Jiri Pirko
2022-05-31 15:05 ` Jakub Kicinski
2022-05-31 15:51 ` Jiri Pirko
2022-05-31 16:08 ` Jakub Kicinski
2022-05-31 19:34 ` Jiri Pirko
2022-05-31 22:41 ` Jakub Kicinski
2022-06-01 7:35 ` Jiri Pirko [this message]
2022-05-28 15:58 ` David Ahern
2022-05-29 9:24 ` Jiri Pirko
2022-05-31 2:11 ` David Ahern
2022-05-31 7:05 ` Jiri Pirko
2022-04-26 15:24 ` Andrew Lunn
2022-04-27 7:37 ` Jiri Pirko
2022-04-26 6:47 ` Jiri Pirko
2022-04-26 12:27 ` Andrew Lunn
2022-04-26 12:41 ` Jiri Pirko
2022-04-26 13:45 ` Andrew Lunn
2022-04-26 14:05 ` Jiri Pirko
2022-04-26 15:36 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YpcWqL5By3hU+AVP@nanopsycho \
--to=jiri@resnulli.us \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=idosch@idosch.org \
--cc=idosch@nvidia.com \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox