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

[Jakub Kicinski <kuba@kernel.org>]

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

> 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?