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

[address@hidden]

OK, replying to the list, as this seems to begetting a longer discussion :-)


Jonathan Larmour wrote:
> 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.
>   

I don't know about that: we would lose the possiblity to allocate full 
MSS-sized pbufs when starting a new segment and filling up that pbuf. 
This is not implemented right now, but I think it would a) save a lot of 
pbuf allocation, b) be faster in tcp_enqueue (just check if the segment 
has space and copy some data) and c) allow zero copy for many MACs that 
can't handle pbuf chains. To limit wasted memory, we could do this only 
for conections that don't have the nagle algorithm turned off.

If we changed the API to only allow enqueueing prefilled pbufs, we'd 
always have every call to tcp_write 'waste' a pbuf.


I'd like to sum up what has to be / can be improved in tcp_write/_enqueue:
- prevent segments with size less than MSS being sent when there's 
enough data enqueued
- don't allocate more pbufs that we need
- take care of MAC limitations (e.g. no pbuf chains, special pbuf 
length, etc.)
- accept prefilled pbufs to prevent copying for applications where data 
is generated (can be generated directly into a pbuf)


The first can be done by a simple change in tcp_enqueue (unfortunately, 
I don't have the time right now to check your patch, Jakob).
The second could need a change in the API (need to know the fill status 
of the pbuf in the last segment), the third also (need to know the netif 
to be used). The fourth definitively needs an API change (to accept 
pbuf, not a data pointer).

Simon