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

[address@hidden]

Jakob Stoklund Olesen schrieb:
> OK, back on lwip-devel...
>
> Jonathan Larmour <address@hidden> writes:
>   
> > 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 think I understand why this would be a good idea. Could you
> elaborate, please?
>   

I guess you did that yourself, in your last post: zero copy for TCP can 
only be done if a) the application has a callback that memory passed to 
tcp_enqueue is not used any more or b) the application passes pbufs to 
TCP, and is not allowed to re-use them -> the pbufs are for free use by 
TCP and are freed when they are ACKed.

I guess all your scenarios can be solved like this:

- the 'old' form of tcp_enqueue (takes a memory pointer) copies data 
into newly allocated pbufs, creates a checksum while copying (see task 
#6849/patch #6253) and is able to use one pbuf only per segment (the 
last can be disabled for SO_NODELAY to prevent waisting space)

- a 'new' function can take pbufs and directly enqueue them in old (if 
not full) or new segments (to be called by a raw-only application: the 
application is responsible of using a pbuf that is optimal for the MAC; 
we could provide functions to allocate such pbufs)


I don't think these changes would make the API too complicated: we would 
just have 2 forms of tcp_write: data pointer and pbuf. Of course there's 
still the question of how to handle options, but that's a minor one, I 
guess.

Simon