[lwip-devel] [task #7896] Support zero-copy drivers

[Jonathan Larmour]

URL:
  <http://savannah.nongnu.org/task/?7896>

                 Summary: Support zero-copy drivers
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: jifl
            Submitted on: Thursday 03/27/2008 at 22:28
                Category: None
         Should Start On: Thursday 03/27/2008 at 00:00
   Should be Finished on: Friday 06/27/2008 at 00:00
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 1.4.0
                  Effort: 0.00

    _______________________________________________________

Details:

This is an off-shoot from task #6735 which is now invalid. Here's what I
wrote there:


There's a lot to do to support zero-copy transmits and receives. For
receives, there are usually requirements for things such as using specific
memory regions (PCI windows, or dedicated DMA regions, or on-chip RAM, etc.),
as well as alignment and buffer size constraints. One port I've already done
with my own zero-copy rx mods is to AT91SAM7X which uses fixed 128-byte
buffers, thus requiring fixed 128-byte pool pbufs. Fortunately I could still
keep the existing pool structure, but that won't be true on other systems - it
will need to be possible to separate the struct pbuf, from the following pool
memory itself. The simplest way I can think of is to keep the struct pbuf and
the pbuf memory itself in parallel arrays. So if you have the pbuf start, then
since the pbufs are of constant size and you know the base, you can easily
calculate the index of this pbuf, and therefore the index of the corresponding
struct pbuf.

Another requirement is that drivers need to be informed when more of that
pool memory becomes available, as often the hardware has its own circular
buffer lists, and these will need to be marked as available again, once a pool
pbuf has been freed.

So far I only have a solution for one ethernet driver at a time. Implementing
this for multiple ones (efficiently) is more tricky since of course it's
possible for drivers to have different requirements. The easiest solution is
probably to say they can't do it then.






    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?7896>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/