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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Apr 2020 07:32:46 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Jakub Kicinski <kuba@...nel.org>
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



> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Tuesday, March 31, 2020 11:03 PM
> 
> On Tue, 31 Mar 2020 07:45:51 +0000 Parav Pandit wrote:
> > > In fact very little belongs to the port in that model. So why have
> > > PCI ports in the first place?
> > >
> > for few reasons.
> > 1. PCI ports are establishing the relationship between eswitch port
> > and its representor netdevice.
> > Relying on plain netdev name doesn't work in certain pci topology
> > where netdev name exceeds 15 characters.
> > 2. health reporters can be at port level.
> 
> Why? The health reporters we have not AFAIK are for FW and for queues
> hanging. Aren't queues on the slice and FW on the device?
There are multiple heath reporters per object.
There are per q health reporters on the representor queues (and representors are attached to devlink port).
Can someone can have representor netdev for an eswitch port without devlink port?
No, net/core/devlink.c cross verify this and do WARN_ON.
So devlink port for eswitch are linked to representors and are needed.
Their existence is not a replacement for representing 'portion of the device'.

> 
> > 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'.