Darren Reed wrote:
Min Miles Xu wrote:
...
Hi Jason,
I've been working on the buffer management on the rx side,
consolidating the dma rx buffer pool of all the GLD instances
(port/ring). The driver can simply ask for a number of buffer from the
framework and use it, pass it up to the stack. It's the framework's
responsibility to recycle the buffer returned. So everything is
transparent to the drivers. Another prominent advantage of doing so is
that the buffer can be shared among instances. New Intel 10G NICs have
128 rings. The existing way of allocating buffer for each ring is a
big waste of memory.
I already have a prototype for e1000g and ixgbe. But I need some more
time to conduct experiments and refine it. Then I will handle it out
for reviews. The code to be integrated may be applied to ixgbe only,
then applies to other NIC drivers.
Something that we need to do work on is zero-copy receive.
And for it to be available with all socket types.
In this case, all the buffers are mapped into the kernel memory
space from the application memory space.
At present we only have a limited form of zero-copy transmit for
TCP for some special network interfaces.
They're not special.. They just set the DL_CAPAB_ZEROCOPY flag.
Which is done in GLDv2 by setting GLD_CAP_ZEROCOPY (GLDv2), or
in GLDv3 by *not* setting MAC_CAPAB_NO_ZCOPY.
However, one of the primary uses of zero-copy sends is sendfile().
and thanks to 6459866, it is faster to copy. For context, see
http://markmail.org/message/oeowmlvfqi3kzttf
Drew
_______________________________________________
networking-discuss mailing list
[email protected]
