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: <20221128153719.2b6102cc@kernel.org>
Date:   Mon, 28 Nov 2022 15:37:19 -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 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 :(

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ