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: <20200402061643.GB2199@nanopsycho.orion>
Date:   Thu, 2 Apr 2020 08:16:43 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Parav Pandit <parav@...lanox.com>,
        "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

Wed, Apr 01, 2020 at 10:12:31PM CEST, kuba@...nel.org wrote:
>On Wed, 1 Apr 2020 07:32:46 +0000 Parav Pandit wrote:
>> > 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'.
>
>I don't understand what you're trying to say. My question was why are
>queues not on the "slice"? If PCIe resources are on the slice, then so
>should be the health reporters.

I agree. These should be attached to the slice.


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