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

Message-ID: <20210422093642.20c9e89e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 22 Apr 2021 09:36:42 -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 Thu, 22 Apr 2021 03:55:50 +0000 Parav Pandit wrote:
> > On Wed, 21 Apr 2021 10:47:18 -0700 Saeed Mahameed wrote:  
> > > From: Parav Pandit <parav@...dia.com>
> > >
> > > Extended SF port attributes to have optional external flag similar to
> > > PCI PF and VF port attributes.
> > >
> > > External atttibute is required to generate unique phys_port_name when
> > > PF number and SF number are overlapping between two controllers
> > > similar to SR-IOV VFs.
> > >
> > > When a SF is for external controller an example view of external SF
> > > port and config sequence.
> > >
> > > On eswitch system:
> > > $ devlink dev eswitch set pci/0033:01:00.0 mode switchdev
> > >
> > > $ devlink port show
> > > pci/0033:01:00.0/196607: type eth netdev enP51p1s0f0np0 flavour
> > > physical port 0 splittable false
> > > pci/0033:01:00.0/131072: type eth netdev eth0 flavour pcipf controller 1  
> > pfnum 0 external true splittable false  
> > >   function:
> > >     hw_addr 00:00:00:00:00:00
> > >
> > > $ devlink port add pci/0033:01:00.0 flavour pcisf pfnum 0 sfnum 77
> > > controller 1
> > > pci/0033:01:00.0/163840: type eth netdev eth1 flavour pcisf controller 1  
> > pfnum 0 sfnum 77 splittable false  
> > >   function:
> > >     hw_addr 00:00:00:00:00:00 state inactive opstate detached
> > >
> > > phys_port_name construction:
> > > $ cat /sys/class/net/eth1/phys_port_name
> > > c1pf0sf77
> > >
> > > Signed-off-by: Parav Pandit <parav@...dia.com>
> > > Reviewed-by: Jiri Pirko <jiri@...dia.com>
> > > Reviewed-by: Vu Pham <vuhuong@...dia.com>
> > > Signed-off-by: Saeed Mahameed <saeedm@...dia.com>  
> > 
> > I have a feeling I nacked this in the past, but can't find the thread.
> > Was something similar previously posted?  
> 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. Fine as long as Melvidia won't object
to other vendors adding different models of operation in the future,
that is.