netdev - Re: [RFC PATCH net-next 08/19] pds_core: initial VF configuration

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:   Mon, 28 Nov 2022 17:08:28 -0800
From:   Shannon Nelson <shnelson@....com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Shannon Nelson <snelson@...sando.io>, netdev@...r.kernel.org,
        davem@...emloft.net, mst@...hat.com, jasowang@...hat.com,
        virtualization@...ts.linux-foundation.org, drivers@...sando.io
Subject: Re: [RFC PATCH net-next 08/19] pds_core: initial VF configuration

On 11/28/22 4:55 PM, Jakub Kicinski wrote:
> On Mon, 28 Nov 2022 16:37:45 -0800 Shannon Nelson wrote:
>>> If this is a "SmartNIC" there should be alternative solution based on
>>> representors for each of those callbacks, and the device should support
>>> forwarding using proper netdev constructs like bridge, routing, or tc.
>>>
>>> This has been our high level guidance for a few years now. It's quite
>>> hard to move the ball forward since all major vendors have a single
>>> driver for multiple generations of HW :(
>>
>> Absolutely, if the device presented to the host is a SmartNIC and has
>> these bridge and router capabilities, by all means it should use the
>> newer APIs, but that's not the case here.
>>
>> In this case we are making devices available to baremetal platforms in a
>> cloud vendor setting where the majority of the network configuration is
>> controlled outside of the host machine's purview.  There is no bridging,
>> routing, or filtering control available to the baremetal client other
>> than the basic VF configurations.
> 
> Don't even start with the "our device is simple and only needs
> the legacy API" line of arguing :/

I'm not sure what else to say here - yes, we have a fancy and complex 
piece of hardware plugged into the PCI slot, but the device that shows 
up on the PCI bus is a very constrained model that doesn't know anything 
about switchdev kinds of things.

> 
>> The device model presented to the host is a simple PF with VFs, not a
>> SmartNIC, thus the pds_core driver sets up a simple PF netdev
>> "representor" for using the existing VF control API: easy to use,
>> everyone knows how to use it, keeps code simple.
>>
>> I suppose we could have the PF create a representor netdev for each
>> individual VF to set mac address and read stats, but that seems
> 
> Oh, so the "representor" you mention in the cover letter is for the PF?

Yes, a PF representor simply so we can get access to the .ndo_set_vf_xxx 
interfaces.  There is no network traffic running through the PF.

sln