Re: [net-next V3 15/15] Documentation: networking: Add description for multi-pf netdev

[Saeed Mahameed <saeed@kernel.org>]

On 20 Feb 17:33, Jakub Kicinski wrote:
>On Mon, 19 Feb 2024 17:26:36 +0200 Tariq Toukan wrote:
>> > There are multiple devlink instances, right?
>>
>> Right.
>
>Just to be clear I'm asking you questions about things which need to
>be covered by the doc :)
>
>> > In that case we should call out that there may be more than one.
>> >
>>
>> We are combining the PFs in the netdev level.
>> I did not focus on the parts that we do not touch.
>
>> Anyway, the interesting info exposed in sysfs is now available through
>> the netdev genl.
>
>Right, that's true.
>

[...]

>Greg, we have a feature here where a single device of class net has
>multiple "bus parents". We used to have one attr under class net
>(device) which is a link to the bus parent. Now we either need to add
>more or not bother with the linking of the whole device. Is there any
>precedent / preference for solving this from the device model
>perspective?
>
>> Now, is this sysfs part integral to the feature? IMO, no. This in-driver
>> feature is large enough to be completed in stages and not as a one shot.
>
>It's not a question of size and/or implementing everything.
>What I want to make sure is that you surveyed the known user space
>implementations sufficiently to know what looks at those links,
>and perhaps ethtool -i.
>Perhaps the answer is indeed "nothing much will care" and given
>we can link IRQs correctly we put that as a conclusion in the doc.
>
>Saying "sysfs is coming soon" is not adding much information :(
>

linking multiple parent devices at the netdev subsystems doesn't add
anything, the netdev abstraction should stop at linking rx/tx channels to
physical irqs and NUMA nodes, complicating the sysfs will required a proper
infrastructure to model the multi-pf mode for all vendors to use uniformly,
but for what? currently there's no configuration mechanism for this feature
yet, and we don't need it at the moment, once configuration becomes necessary,
I would recommend adding one infrastructure to all vendors to register to
at the parent device level, which will handle the sysfs/devlink abstraction, 
and leave netdev abstraction as is (IRQ/NUMA) and maybe take this a step 
further and give the user control of attaching specific channels to specific
IRQs/NUMA nodes.