netdev - Re: [oss-drivers] [RFC v2] 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]

Message-ID: <20200513130008.GA24409@netronome.com>
Date:   Wed, 13 May 2020 15:00:09 +0200
From:   Simon Horman <simon.horman@...ronome.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        parav@...lanox.com, yuvalav@...lanox.com, jgg@...pe.ca,
        saeedm@...lanox.com, leon@...nel.org,
        andrew.gospodarek@...adcom.com, michael.chan@...adcom.com,
        moshe@...lanox.com, ayal@...lanox.com, eranbe@...lanox.com,
        vladbu@...lanox.com, kliteyn@...lanox.com, dchickles@...vell.com,
        sburla@...vell.com, fmanlunas@...vell.com, tariqt@...lanox.com,
        oss-drivers@...ronome.com, snelson@...sando.io,
        drivers@...sando.io, aelior@...vell.com,
        GR-everest-linux-l2@...vell.com, grygorii.strashko@...com,
        mlxsw@...lanox.com, idosch@...lanox.com, markz@...lanox.com,
        jacob.e.keller@...el.com, valex@...lanox.com,
        linyunsheng@...wei.com, lihong.yang@...el.com,
        vikas.gupta@...adcom.com, sridhar.samudrala@...el.com
Subject: Re: [oss-drivers] [RFC v2] current devlink extension plan for NICs

On Fri, May 01, 2020 at 11:14:49AM +0200, Jiri Pirko wrote:
> Hi all.
> 
> First, I would like to apologize for very long email. But I think it
> would be beneficial to the see the whole picture, where we are going.
> 
> Currently we are working internally on several features with
> need of extension of the current devlink infrastructure. I took a stab
> at putting it all together in a single txt file, inlined below.
> 
> Most of the stuff is based on a new port sub-object called "func"
> (called "slice" previously" and "subdev" originally in Yuval's patchsets
> sent some while ago).
> 
> The text describes how things should behave and provides a draft
> of user facing console input/outputs. I think it is important to clear
> that up before we go in and implement the devlink core and
> driver pieces.
> 
> I would like to ask you to read this and comment. Especially, I would
> like to ask vendors if what is described fits the needs of your
> NIC/e-switch.
> 
> Please note that something is already implemented, but most of this
> isn't (see "what needs to be implemented" section).
> 
> v1->v2
> - mainly move from separate slice object into port/func subobject
> - couple of small fixes here and there
> 
> 
> 
> 
> ==================================================================
> ||                                                              ||
> ||            Overall illustration of example setup             ||
> ||                                                              ||
> ==================================================================
> 
> Note that there are 2 hosts in the picture. Host A may be the smartnic host,
> Host B may be one of the hosts which gets PF. Also, you might omit
> the Host B and just see Host A like an ordinary nic in a host.
> 
> Note that the PF is merged with physical port representor.
> That is due to simpler and flawless transition from legacy mode and back.
> The devlink_ports and netdevs for physical ports are staying during
> the transition.

Hi Jiri,

I'm probably missing something obvious but this merge seems at odds with
the Netronome hardware.

We model a PF as, in a nutshell, a PCIE link to a host. A chip may have
one or more, and these may go to the same or different hosts. A chip may
also have one or more physical ports. And there is no strict relationship
between a PF and a physical port.

Of course in SR-IOV legacy mode, there is such a relationship, but its not
inherent to the hardware nor the NFP driver implementation of SR-IOV
switchdev mode.

...