On Mon, 28 Nov 2022 14:25:56 -0800 Shannon Nelson wrote:

On 11/28/22 10:28 AM, Jakub Kicinski wrote:

quoted

On Fri, 18 Nov 2022 14:56:45 -0800 Shannon Nelson wrote:  

quoted

+     .ndo_set_vf_vlan        = pdsc_set_vf_vlan,
+     .ndo_set_vf_mac         = pdsc_set_vf_mac,
+     .ndo_set_vf_trust       = pdsc_set_vf_trust,
+     .ndo_set_vf_rate        = pdsc_set_vf_rate,
+     .ndo_set_vf_spoofchk    = pdsc_set_vf_spoofchk,
+     .ndo_set_vf_link_state  = pdsc_set_vf_link_state,
+     .ndo_get_vf_config      = pdsc_get_vf_config,
+     .ndo_get_vf_stats       = pdsc_get_vf_stats,  

These are legacy, you're adding a fancy SmartNIC (or whatever your
marketing decided to call it) driver. Please don't use these at all.  

Since these are the existing APIs that I am aware of for doing this kind 
of VF configuration, it seemed to be the right choice.  I'm not aware of 
any other obvious solutions.  Do you have an alternate suggestion?

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