Really sorry for the noise, mail is in lkml properly now. I failed at marking it as plain text.
You can disregard this one. Regards Ilias On 30 January 2018 at 10:02, Ilias Apalodimas <ilias.apalodi...@linaro.org> wrote: > 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 > Ilias
