netdev - Re: [PATCH net-next 00/13] nfp: abm: add basic support for advanced buffering NIC

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]

Date:   Tue, 22 May 2018 00:56:59 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        oss-drivers@...ronome.com, Andy Gospodarek <gospo@...adcom.com>,
        linux-internal@...lanox.com
Subject: Re: [PATCH net-next 00/13] nfp: abm: add basic support for advanced
 buffering NIC

On Mon, May 21, 2018 at 11:32 PM, Or Gerlitz wrote:
> On Tue, May 22, 2018 at 8:12 AM, Jakub Kicinski wrote:
>> Hi!
>>
>> This series lays groundwork for advanced buffer management NIC feature.
>> It makes necessary NFP core changes, spawns representors and adds devlink
>> glue.  Following series will add the actual buffering configuration (patch
>> series size limit).
>>
>> First three patches add support for configuring NFP buffer pools via a
>> mailbox.  The existing devlink APIs are used for the purpose.
>>
>> Third patch allows us to perform small reads from the NFP memory.
>>
>> The rest of the patch set adds eswitch mode change support and makes
>> the driver spawn appropriate representors.
>
> Hi Jakub,
>
> Could you provide more higher level description on the abm use-case
> and nature of these representors? I understand that under abm you are
> modeling the nic as switch with vNIC ports, does vNIC port and vNIC
> port rep have the same characteristics as VF and VF rep (xmit on one side
> <--> send on 2nd side),  does traffic is to be offloaded using TC, etc.
> What one would be doing with vNIC instance, hand it to container ala the Intel
> VMDQ concept?
> can this be seen as veth HW offload? etc

Yes, the reprs can be used like VF reprs but that's not the main use
case. We are targeting container world with ABM, so no VFs and no
SR-IOV.  There is only one vNIC per port and no veth offload etc. In
the most basic scenario with 1 PF corresponding to 1 port there is no
real use for switching.

The main purpose here is that we want to setup the buffering and QoS
inside the NIC (both for TX and RX) and then use eBPF to perform
filtering, queue assignment and per-application RSS. That's pretty
much it at this point.

Switching if any will be a basic bridge offload.  QoS configuration
will all be done using TC qdisc offload, RED etc. exactly like mlxsw
:)