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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <75072b2a-0b69-d519-4174-6d61d027f7d4@amd.com>
Date:   Mon, 28 Nov 2022 16:37:45 -0800
From:   Shannon Nelson <shnelson@....com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Shannon Nelson <snelson@...sando.io>, netdev@...r.kernel.org,
        davem@...emloft.net, mst@...hat.com, jasowang@...hat.com,
        virtualization@...ts.linux-foundation.org, drivers@...sando.io
Subject: Re: [RFC PATCH net-next 08/19] pds_core: initial VF configuration

On 11/28/22 3:37 PM, Jakub Kicinski wrote:
> On Mon, 28 Nov 2022 14:25:56 -0800 Shannon Nelson wrote:
>> On 11/28/22 10:28 AM, Jakub Kicinski wrote:
>>> On Fri, 18 Nov 2022 14:56:45 -0800 Shannon Nelson wrote:
>>>> +     .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 :(

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.

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

sln