Re: [lwip-users] tcp_recved

[Bill Auerbach]

>As a general advisory, I'm with on that, Kieran.
>
>However, I think Bill's way might be correct in his very special case
>here: calling tcp_recved from the receive callback without freeing the
>received pbuf does not hurt the stack. The only problem might be running
>out of pbufs (so newly arriving packets are dropped, like Kieran wrote).
>But as long as you impose an outer limit on the number of pbufs being
>buffered like that (on all connections, globally!), this should not have
>a negative impact on performance or what soever.

Would this limit me to TCP_WND of received data?  My thinking is if I don't
run out of pbufs and call tcp_reced on every receive callback, I would be
buffering using pbufs instead of copying into a memory buffer (using less
pbufs).  I plan on using something like pbuf_cat to build this list keeping
p->tot_len (the top) valid.  When p->tot_len is the size that's sent, I can
process the data.  pbuf_cat is inefficient for large chains, but since I own
the chain, I can link these more efficiently.  Yes, I know pbufs were not
designed for packet chains which is what I am building.  Maybe pbuf_cat_pkt
would be nice - just add to the end keeping the front tot_len correct, and
pbuf_top_pkt to remove the first updating p->next->tot_len.  Neither of
these would entail traversing the list.

To really support zero-copy large (MB) receives, I can't think of anything
more efficient to do, can you?

Bill