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

Powered by blists - more mailing lists