netdev - Re: [net-next 06/11] devlink: Extend SF port attributes to have external attribute

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] [day] [month] [year] [list]

Message-ID: <20210423161414.5ac326e6@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Fri, 23 Apr 2021 16:14:14 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Parav Pandit <parav@...dia.com>
Cc:     Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...dia.com>, Vu Pham <vuhuong@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [net-next 06/11] devlink: Extend SF port attributes to have
 external attribute

On Fri, 23 Apr 2021 06:53:29 +0000 Parav Pandit wrote:
> > > Your memory is correct.
> > > In past external flag was present but it was always set to false.
> > > So you asked to move out until we set it to true, which we did.
> > > This series uses it as true similar to existing PF and VF eswitch ports of an  
> > external controller.  
> > > Hence, it was removed from past series and done in this series that actually  
> > uses it.
> > 
> > Right. I still think it's a weird model to instantiate an SF from the controller
> > side, but if your HW is too limited to support nested switching that's fine.  
> 
> I can't locate the old email thread, but we discussed the use cases.
> Nested switch may be solution to some use case but not for the current one.
> In the use case of interest, multiple tenant applications are running in a bare-metal host.
> Such host should not have access to switching rate, policy, filter rules, encryption keys.
> Each such tenant is assigned one VF or SF running on the host system.

Bare metal, and multiple tenants do not compute for me but that's fine.

> Also, this model doesn't prevent nested switch implementation for mlx5 and other vendors.
> Each such nested switch in that case will do its own programming at its own level.
> Such model is already described by Jiri in the RFCv3 [1].

As I said, I'm okay with the changes, please repost if they were
dropped from PW already.