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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 31 May 2022 17:51:36 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Ido Schimmel <idosch@...sch.org>, Ido Schimmel <idosch@...dia.com>,
        netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
        jiri@...dia.com, petrm@...dia.com, dsahern@...il.com,
        andrew@...n.ch, mlxsw@...dia.com
Subject: Re: [PATCH net-next 00/11] mlxsw: extend line card model by devices
 and info

Tue, May 31, 2022 at 05:05:55PM CEST, kuba@...nel.org wrote:
>On Tue, 31 May 2022 09:11:27 +0200 Jiri Pirko wrote:
>> >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?
>
>Group of components. As explained component has an existing meaning,
>we can't reuse the term with a different one now.

I still don't follow. I don't want to reuse it.
Really, could you be more specific and show examples, please?


>
>> >> 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
>
>lc2 is the group 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
>
>Yup, it'll make DaveA happy as well.
>
>> 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                                             
>
>Yup.

Set, you say "yup" but below you say it should be in a separate nest.
That is confusing me.


>                                                            
>> But that would break the existing JSON output, because "running" is an array:
>>                 "running": {                                             
>>                     "fw": "1.2.3",                                       
>>                     "fw.mgmt": "10.20.30"                                
>>                 },                                                       
>
>No, the lc versions should be in separate nests. Since they are not
>updated when flashing main FW mixing them into existing versions would
>break uAPI.

Could you please draw it out for me exacly as you envision it? We are
dancing around it, I can't really understand what exactly do you mean.


>
>> 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?
>
>BTW how do you intend to activate the new FW? Extend the reload command?

Not sure now. Extending reload is an option. Have to think about it.