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 09:32:39 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     David Miller <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        oss-drivers@...ronome.com,
        linux-internal <linux-internal@...lanox.com>,
        Andy Gospodarek <gospo@...adcom.com>
Subject: Re: [PATCH net-next 00/13] nfp: abm: add basic support for advanced
 buffering NIC

On Tue, May 22, 2018 at 8:12 AM, Jakub Kicinski
<jakub.kicinski@...ronome.com> 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

Or.


> Jakub Kicinski (13):
>   nfp: move rtsym helpers to pf code
>   nfp: add support for per-PCI PF mailbox
>   nfp: add shared buffer configuration
>   nfp: core: allow 4-byte aligned accesses to Memory Units
>   nfp: abm: add initial active buffer management NIC skeleton
>   nfp: abm: create project-specific vNIC structure
>   nfp: add app pointer to port representors
>   devlink: don't take instance lock around eswitch mode set
>   nfp: add devlink_eswitch_mode_set callback
>   nfp: abm: spawn port netdevs
>   nfp: abm: force Ethternet port up
>   nfp: use split in naming of PCIe PF ports
>   nfp: assign vNIC id as phys_port_name of vNICs which are not ports