netdev - AF_PACKET V4/AF_XDP userspace API questions

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>] [day] [month] [year] [list]

Message-ID: <CAC_iWjJMt1T_nCWyF98For6PxB5tv+aACb0Qkz=UcSKqLFp4Vg@mail.gmail.com>
Date:   Tue, 30 Jan 2018 10:06:59 +0200
From:   Ilias Apalodimas <ilias.apalodimas@...aro.org>
To:     netdev@...r.kernel.org, magnus.karlsson@...el.com,
        bjorn.topel@...el.com
Cc:     Francois Ozog <francois.ozog@...aro.org>,
        MykytaI Iziumtsev <mykyta.iziumtsev@...aro.org>
Subject: AF_PACKET V4/AF_XDP userspace API questions

We've noticed 3 different hardware approaches in receiving payloads

1. Host driver needs to pre-load descriptor ring with addresses of RAM
buffers to write arriving data.
The "standard" functionality for most NICs is (in little detail) fetch
the descriptor, write the payload to host RAM and update the
descriptor accordingly.
So for these NICs, buffer addresses are provided in RX descriptors (RX
descriptors are two-way communication entity).
This translates to "1 ring + 1 buffer array" model, or the packet
array model in short.

2. There's a category of NICs (Chelsio and Netcope are the ones we are
aware of) that split that into two one-way entities:
One to communicate buffer addresses from host to NIC and one to
communicate packets/payloads from NIC to host.
So the driver provides a set of unstructured, contiguous memory areas
to the NIC, the NIC decides where to place the packets in memory and
updates the descriptors accordingly (the descriptor ring is not
pre-loaded with any data and the NIC is free to write the packet
anywhere in the provided contiguous memory).
This is a "1 ring + 1 set of areas" model, or the tape model in short.

3. The last hardware approach we are aware of is NICs that you provide
multiple array buffers (128, 256, 1500, 9000 etc).
The NIC then decides in which array slot to place the packet depending
on it's size.
This is "1 ring + X buffer arrays" model or the multi packet array in short.

Is memory schemes 2 and 3 supported? If not do you plan on supporting them?

Regards