netdev - Re: [RFC] current devlink extension plan for NICs

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: <20200408095914.772dfdf3@kicinski-fedora-PC1C0HJN>
Date:   Wed, 8 Apr 2020 09:59:14 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Parav Pandit <parav@...lanox.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Yuval Avnery <yuvalav@...lanox.com>,
        "jgg@...pe.ca" <jgg@...pe.ca>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "leon@...nel.org" <leon@...nel.org>,
        "andrew.gospodarek@...adcom.com" <andrew.gospodarek@...adcom.com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        Moshe Shemesh <moshe@...lanox.com>,
        Aya Levin <ayal@...lanox.com>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        Vlad Buslov <vladbu@...lanox.com>,
        Yevgeny Kliteynik <kliteyn@...lanox.com>,
        "dchickles@...vell.com" <dchickles@...vell.com>,
        "sburla@...vell.com" <sburla@...vell.com>,
        "fmanlunas@...vell.com" <fmanlunas@...vell.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>,
        "snelson@...sando.io" <snelson@...sando.io>,
        "drivers@...sando.io" <drivers@...sando.io>,
        "aelior@...vell.com" <aelior@...vell.com>,
        "GR-everest-linux-l2@...vell.com" <GR-everest-linux-l2@...vell.com>,
        "grygorii.strashko@...com" <grygorii.strashko@...com>,
        mlxsw <mlxsw@...lanox.com>, Ido Schimmel <idosch@...lanox.com>,
        Mark Zhang <markz@...lanox.com>,
        "jacob.e.keller@...el.com" <jacob.e.keller@...el.com>,
        Alex Vesker <valex@...lanox.com>,
        "linyunsheng@...wei.com" <linyunsheng@...wei.com>,
        "lihong.yang@...el.com" <lihong.yang@...el.com>,
        "vikas.gupta@...adcom.com" <vikas.gupta@...adcom.com>,
        "magnus.karlsson@...el.com" <magnus.karlsson@...el.com>
Subject: Re: [RFC] current devlink extension plan for NICs

On Wed, 8 Apr 2020 05:07:04 +0000 Parav Pandit wrote:
> > > > > 3. In future at eswitch pci port, I will be adding dpipe support
> > > > > for the internal flow tables done by the driver.
> > > > > 4. There were inconsistency among vendor drivers in using/abusing
> > > > > phys_port_name of the eswitch ports. This is consolidated via
> > > > > devlink port in core. This provides consistent view among all
> > > > > vendor drivers.
> > > > >
> > > > > So PCI eswitch side ports are useful regardless of slice.
> > > > >  
> > > > > >> Additionally devlink port object doesn't go through the same
> > > > > >> state machine as that what slice has to go through.
> > > > > >> So its weird that some devlink port has state machine and some
> > > > > >> doesn't.  
> > > > > >
> > > > > > You mean for VFs? I think you can add the states to the API.
> > > > > >  
> > > > > As we agreed above that eswitch side objects (devlink port and
> > > > > representor netdev) should not be used for 'portion of device',  
> > > >
> > > > We haven't agreed, I just explained how we differ.  
> > >
> > > You mentioned that " Right, in my mental model representor _is_ a port
> > > of the eswitch, so repr would not make sense to me."
> > >
> > > With that I infer that 'any object that is directly and _always_
> > > linked to eswitch and represents an eswitch port is out of question,
> > > this includes devlink port of eswitch and netdev representor. Hence,
> > > the comment 'we agree conceptually' to not involve devlink port of
> > > eswitch and representor netdev to represent 'portion of the device'.  
> > 
> > I disagree, repr is one to one with eswitch port. Just because repr is
> > associated with a devlink port doesn't mean devlink port must be associated
> > with a repr or a netdev.  
> Devlink port which is on eswitch side is registered with switch_id and also linked to the rep netdev.
> From this port phys_port_name is derived.
> This eswitch port shouldn't represent 'portion of the device'.

switch_id is per port, so it's perfectly fine for a devlink port not to
have one, or for two ports of the same device to have a different ID.

The phys_port_name argument I don't follow. How does that matter in the
"should we create another object" debate?

IMO introducing the slice if it's 1:1 with ports is a no-go. I also
don't like how creating a slice implicitly creates a devlink port in
your design. If those objects are so strongly linked that creating one
implies the other they should just be merged.

I'm also concerned that the slice is basically a non-networking port.
I bet some of the things we add there will one day be useful for
networking or DSA ports.

So I'd suggest to maybe step back from the SmartNIC scenario and try to
figure out how slices are useful on their own.