[lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY

[Jonathan Larmour]

Follow-up Comment #34, task #6735 (project lwip):

Unfortunately I will be up to my ears for the next 3 weeks or so, and even
then, I need to update my own port to 1.3.0 first. If someone else wants to
run with this feel free, however given Kieran's comment, really this
particular task is now invalid. If pbufs can't be reused, we no longer need a
separate PBUF_RAM_NOCOPY pbuf type.

But there's still 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.

Anyway, I'm closing this task as invalid, and I'll open a new task for the
above.


    _______________________________________________________

Reply to this item at:

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

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