netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Sat, 28 May 2022 11:09:01 +0200	[thread overview]
Message-ID: <YpHmrdCmiRagdxvt@nanopsycho> (raw)
In-Reply-To: <20220527171038.52363749@kernel.org>

Sat, May 28, 2022 at 02:10:38AM CEST, kuba@kernel.org wrote:
>On Fri, 27 May 2022 09:27:47 +0200 Jiri Pirko wrote:
>> Okay. So the output of devlink dev info would be extended by
>> "components" nest. This nest would carry array of components which
>> contain versions. The name of the component is openin each array member
>> nest:
>> 
>> $ devlink dev info
>> pci/0000:01:00.0:
>>   driver mlxsw_spectrum2
>>   versions:
>>       fixed:
>>         hw.revision A0
>>         fw.psid MT_0000000199
>>       running:
>>         fw.version 29.2010.2302
>>         fw 29.2010.2302
>>   components:
>>     lc1:
>
>Is the "lc1" free-form or generated by the core based on subobjects?
>Is it carried as a string or object type + id?

It could be both:
1) for line cards I plan to have a helper to have this generated by core
2) for other FW objects, it is up to the driver.


>
>I guess my suggestion of a CLI mockup has proven its weakness :)

I'm not sure I understand what you mean by this sentence. Could you
please be more blunt? You know, my english is not so good to understand
some hidden meanings :)



>
>>       versions:
>>         fixed:
>>           hw.revision 0
>>           fw.psid MT_0000000111
>>         running:
>>           fw 19.2010.1310
>>           ini.version 4
>>     lc2:
>>       versions:
>>         fixed:
>>           hw.revision 0
>>           fw.psid MT_0000000111
>>         running:
>>           fw 19.2010.1310
>>           ini.version 4
>>     someothercomponentname:
>>       versions:
>>         running:
>> 	   fw: 888
>> 
>> Now on top of exsisting "devlink dev flash" cmd without component, user
>> may specify the component name from the array above:
>> 
>> $ devlink dev flash pci/0000:01:00.0 component lc1 file mellanox/fw-AGB-rel-19_2010_1312-022-EVB.mfa2
>> 
>> $ devlink dev flash pci/0000:01:00.0 component someothercomponentname file foo.bin
>> 
>> Note this is generic vehicle, line cards would benefit but it is usable
>> for multiple ASIC FW partitions for example.
>> 
>> Note that on "devlink dev flash" there is no change. This is implemented
>> currently. Only "devlink dev info" is extended to show the component
>> list.
>
>I sort of assumed that the DEVLINK_ATTR_INFO_VERSION_NAME is the
>component, the docs also use the word "component" for it. 

Okay, that I didn't see.

>
>For the nfp for instance we had "fw.app" for the datapath microcode and
>"fw.mgmt" for the control processor. These are separate partitions on
>the flash. I don't think we ever implemented writing them separately
>but it's certainly was our internal plan at some point.

Okay, so what you say it, we already have components in "devlink dev
info". Like you pointed out as an example:
  fw.app
  fw.mgmt
so the flash comment would be:
  devlink dev flash pci/0000:01:00.0 component fw.app file foo.bin
  devlink dev flash pci/0000:01:00.0 component fw.mgmt file bar.bin
?

If yes, what should be the default in case component is not defined? Do
we need to expose it in "devlink dev info"? How?

So to extend this existing facility with my line card example, we would
have:

$ devlink dev info
pci/0000:01:00.0:
   driver mlxsw_spectrum2
   versions:
       fixed:
         hw.revision A0
         fw.psid MT_0000000199
	 lc1.hw.revision 0
	 lc1.fw.psid MT_0000000111
	 lc2.hw.revision 0
	 lc2.fw.psid MT_0000000111
       running:
         fw.version 29.2010.2302
         fw 29.2010.2302
	 lc1.fw 19.2010.1310
	 lc1.ini.version 4
	 lc2.fw 19.2010.1310
	 lc2.ini.version 4

And then:
devlink dev flash pci/0000:01:00.0 component lc1.fw file mellanox/fw-AGB-rel-19_2010_1312-022-EVB.mfa2

Does this sound correct?

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?

Thanks!



  reply	other threads:[~2022-05-28  9:09 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 [this message]
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
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=YpHmrdCmiRagdxvt@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;
as well as URLs for NNTP newsgroup(s).