>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 _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
