Re: [PATCH net-next 00/11] mlxsw: extend line card model by devices and info

Jiri Pirko
2022-05-31T07:11:33Z

Mon, May 30, 2022 at 09:54:08PM CEST, kuba@kernel.org wrote:
>On Sun, 29 May 2022 11:23:01 +0200 Jiri Pirko wrote:
>> >Let's step back and look from the automation perspective again.
>> >Assuming we don't want to hardcode matching "lc$i" there how can
>> >a generic FW update service scan the dev info and decide on what
>> >dev flash command to fire off?
>>
>> Hardcode matching lc$i? I don't follow. It is a part of the
>> version/component name.
>> So if devlink dev info outputs:
>> lc2.fw 19.2010.1310
>> then you use for devlink dev flash:
>> devlink dev flash pci/0000:01:00.0 component lc2.fw file mellanox/fw-AGB-rel-19_2010_1312-022-EVB.mfa2
>> Same name, same string.
>>
>> What am I missing?
>
>Nevermind, I think we can iterate over all the groupings.
>Since I hope you agreed that component has an established

Yeah, component=version. I will send a RFC soon that tights it together.

>meaning can we use group instead?

Group of what? Could you provide me example what you mean?

>
>> >> Also, to avoid free-form, I can imagine to have per-linecard info_get() op
>> >> which would be called for each line card from devlink_nl_info_fill() and
>> >> prefix the "lcX" automatically without driver being involved.
>> >>
>> >> Sounds good?
>> >
>> >Hm. That's moving the matryoshka-ing of the objects from the uAPI level
>> >to the internals.
>> >
>> >If we don't do the string prefix but instead pass the subobject info to
>> >the user space as an attribute per version we can at least avoid
>> >per-subobject commands (DEVLINK_CMD_LINECARD_INFO_GET). Much closer to
>> >how health reporters are implemented than how params are done, so I
>> >think it is a good direction.
>>
>> Sorry, I'm a bit lost. Could you please provide some example about how
>> you envision it? For me it is a guessing game :/
>> My guess is you would like to add to the version nest where
>> DEVLINK_ATTR_INFO_VERSION_NAME resides for example
>> DEVLINK_ATTR_LINECARD_INDEX?
>>
>> Correct?
>
>Yup.

Hmm, in that case, I'm not sure how to do this. As cmd options and
outputs should match, we would have:

devlink dev info
lc2.fw 19.2010.1310

here lc2 and fw are concatenated from DEVLINK_ATTR_LINECARD_INDEX and DEVLINK_ATTR_INFO_VERSION_NAME

Now on devlink dev flash side, when I pass "component lc2.fw", how could
the "devlink dev flash" know to divide it to DEVLINK_ATTR_LINECARD_INDEX
and FLASH_COMPONENT? Should I parse the cmd line option and figure the
"lcX." prefix into an attribute?

Or, we would have to have something like:
devlink dev flash pci/0000:01:00.0 lc 2 component fw file mellanox/fw-AGB-rel-19_2010_1312-022-EVB.mfa2

But to be consistent with the output, we would have to change "devlink
dev info" to something like:
pci/0000:01:00.0:
versions:
running:
fw 1.2.3
fw.mgmt 10.20.30
lc 2 fw 19.2010.1310

But that would break the existing JSON output, because "running" is an array:
"running": {
"fw": "1.2.3",
"fw.mgmt": "10.20.30"
},

So probably better to stick to "lcx.y" notation in both devlink dev info
and flash and split/squash to attributes internally. What do you think?