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

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 28 Nov 2022 17:08:28 -0800 Shannon Nelson wrote:
> > 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.

Today it is, but I presume it's all FW underneath. So a year from now
you'll be back asking for extensions because FW devs added features.

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

In that case not only have you come up with your own name for 
a SmartNIC, you also managed to misuse one of our existing terms 
in your own way! It can't pass any traffic it's just a dummy to hook
the legacy vf ndos to. It's the opposite of what a repr is.