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]

Date:   Mon, 28 Nov 2022 16:55:22 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Shannon Nelson <shnelson@....com>
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 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?