[lwip-devel] [task #7040] Work on tcp_enqueue

[Jonathan Larmour]

Follow-up Comment #11, task #7040 (project lwip):

Re comment #8: I think that this is leaning even further towards the argument
of shaking up the raw TCP API by allowing data to be written as pbufs rather
than char * + lengths.

Because of the need to allocate pbufs in chunks of the segment size, there
could perhaps be a separate function to allocate a pbuf chain of the
appropriate dimensions. Thinking out loud, that function could also maybe then
be used in future to allocate pbufs complying with zero-copy requirements of
alignment etc.? Or at least possibly call such a function. So for example:

tcp_pbuf_alloc(tcp_pcb, size, pbuf_type)
(where pbuf_type is PBUF_RAM, PBUF_ROM etc.)

and in turn that calls pbuf_alloc_zerocopy(pbuflayer, len, pbuftype, netif)

The netif would be required in order to identify driver/hardware requirements
for alignment, address, etc.

Should something like this even be a prerequisite before doing a full
zero-copy implementation, essentially by being its first phase? I think it
might be. 

There would be API breakage doing this of course. Maybe we could minimise
this by having a wrapper used for backwards compatibility.

Further discussion about this should perhaps move back to lwip-devel though,
as it's out of place in this bug.

Jifl


    _______________________________________________________

Reply to this item at:

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

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