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: <a02cf0e6-98ad-65c4-0363-8fb9d67d2c9c@intel.com>
Date:   Fri, 27 Mar 2020 11:49:10 -0700
From:   "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, 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, magnus.karlsson@...el.com
Subject: Re: [RFC] current devlink extension plan for NICs



On 3/27/2020 9:38 AM, Jakub Kicinski wrote:
> On Fri, 27 Mar 2020 08:47:36 +0100 Jiri Pirko wrote:
>>> So the queues, interrupts, and other resources are also part
>>> of the slice then?
>>
>> Yep, that seems to make sense.
>>
>>> How do slice parameters like rate apply to NVMe?
>>
>> Not really.
>>
>>> Are ports always ethernet? and slices also cover endpoints with
>>> transport stack offloaded to the NIC?
>>
>> devlink_port now can be either "ethernet" or "infiniband". Perhaps,
>> there can be port type "nve" which would contain only some of the
>> config options and would not have a representor "netdev/ibdev" linked.
>> I don't know.
> 
> I honestly find it hard to understand what that slice abstraction is,
> and which things belong to slices and which to PCI ports (or why we even
> have them).

Looks like slice is a new term for sub function and we can consider this
as a VMDQ VSI(intel terminology) or even a Queue group of a VSI.

Today we expose VMDQ VSI via offloaded MACVLAN. This mechanism should 
allow us to expose it as a separate netdev.

> 
> With devices like NFP and Mellanox CX3 which have one PCI PF maybe it
> would have made sense to have a slice that covers multiple ports, but
> it seems the proposal is to have port to slice mapping be 1:1. And rate
> in those devices should still be per port not per slice.
> 
> But this keeps coming back, and since you guys are doing all the work,
> if you really really need it..