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

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 :/

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?

redundant, and as far as I know that still would be missing the other VF 
controls.  Do we have alternate ways for the user to set things like 
trust and spoofchk?