On 11/28/22 4:55 PM, Jakub Kicinski wrote:

On Mon, 28 Nov 2022 16:37:45 -0800 Shannon Nelson wrote:

quoted

quoted

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.

quoted

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