On 11/28/22 5:54 PM, Jakub Kicinski wrote:

On Mon, 28 Nov 2022 17:08:28 -0800 Shannon Nelson wrote:

quoted

quoted

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.

Sure, and that will be the time to add the APIs and code for handling 
the more complex switching and filtering needs.  We leave it out for now 
so as to not have unneeded code waiting for future features that might 
never actually appear, as driver writers are often reminded.

quoted

quoted

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.

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.

Sorry, this seemed to me an reasonable use of the term.  Is there an 
alternative wording we should use for this case?

Are there other existing methods we can use for getting the VF 
configurations from the user, or does this make sense to keep in our 
current simple model?

Thanks,
sln