Re: RE: [RFC net-next 0/8] Introducing subdev bus and devlink extension

[moyufeng]

Hi, Jiri & Jakub

    Generally, a devlink instance is created for each PF/VF. This
facilitates the query and configuration of the settings of each
function. But if some common objects, like the health status of
the entire ASIC, the data read by those instances will be duplicate.

    So I wonder do I just need to apply a public devlink instance for the
entire ASIC to avoid reading the same data? If so, then I can't set
parameters for each function individually. Or is there a better suggestion
to implement it?

    Thanks! ~

On 2019/3/6 0:52, Parav Pandit wrote:
> 
> 
>> -----Original Message-----
>> From: Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx>
>> Sent: Monday, March 4, 2019 7:46 PM
>> To: Parav Pandit <parav@xxxxxxxxxxxx>
>> Cc: Or Gerlitz <gerlitz.or@xxxxxxxxx>; netdev@xxxxxxxxxxxxxxx; linux-
>> kernel@xxxxxxxxxxxxxxx; michal.lkml@xxxxxxxxxxx; davem@xxxxxxxxxxxxx;
>> gregkh@xxxxxxxxxxxxxxxxxxx; Jiri Pirko <jiri@xxxxxxxxxxxx>
>> Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension
>>
>> On Mon, 4 Mar 2019 04:41:01 +0000, Parav Pandit wrote:
>>>>> $ devlink dev show
>>>>> pci/0000:05:00.0
>>>>> subdev/subdev0
>>>>
>>>> Please don't spawn devlink instances.  Devlink instance is supposed
>>>> to represent an ASIC.  If we start spawning them willy nilly for
>>>> whatever software construct we want to model the clarity of the
>>>> ontology will suffer a lot.
>>> Devlink devices not restricted to ASIC even though today it is
>>> representing ASIC for one vendor. Today for one ASIC, it already
>>> presents multiple devlink devices (128 or more) for PF and VFs, two
>>> PFs on same ASIC etc. VF is just a sub-device which is well defined by
>>> PCISIG, whereas sub-device is not. Sub-device do consume actual ASIC
>>> resources (just like PFs and VFs), Hence point-(6) of cover-letter
>>> indicate that the devlink capability to tell how many such sub-devices
>>> can be created.
>>>
>>> In above example, they are created for a given bus-device following
>>> existing devlink construct.
>>
>> No, it's not "representing the ASIC for one vendor".  It's how it works for
>> switches (including mlxsw) and how it was described in the original cover
>> letter:
>>
> Sorry for the confusion.
> I meant to say, my understanding is Netronome creates one devlink instance for whole ASIC.
> Please correct me if this is incorrect.
> mlx5_core driver creates multiple devlink devices for PF and VFs for one ASIC.
> 
>>     Introduce devlink interface and first drivers to use it
>>
>>     There a is need for some userspace API that would allow to expose things
>>     that are not directly related to any device class like net_device of
>>     ib_device, but rather chip-wide/switch-ASIC-wide stuff.
>>
>>     [...]
>>
>> We can deviate from the original intent if need be and dilute the ontology.
>> But let's be clear on the status quo, please.
> Status quo is mlx5_core driver creates multiple devlink devices. It creates for devlink device for each PF and VF of a single ASIC. 
>