I think I understand you're reasoning, after a fashion.
It does seem to be a problem for me because I'm queuing the pbufs in my link layer driver (using pbuf_queue). As a result the length of the pbuf chain reported by pbuf_clen is not what tcp_in expects it to be and so pcb->snd_queuelen ends up wrapping around from 0 to ~255 whenever pbuf_clen(next->p) > pcb->snd_queuelen. This seems to indicate that I shouldn't be using pbuf_queue in the link layer driver and that I should be doing something else instead; pbuf_queue is just so convenient... Might one possible solution be to store the number of pbufs in the segment structure? That or instead of using pbuf_clen use something like pbuf_packetlen which uses the packet end indicator of len == tot_len instead of next == NULL? Thanks, Tom On 11/28/06, Kieran Mansley <[EMAIL PROTECTED]> wrote:
On Mon, 2006-11-27 at 15:57 -0500, Tom Hennen wrote: > Instead it counts the number of pbufs. Why? > Because the configuration limit is also specified in the number of pbufs. This allows people using it to have a much better estimate of the amount of pbufs (and so memory) that can be used for the send queue, which is important if you haven't got much memory (as per most lwIP systems). If we just counted segments, which can vary somewhat in size, you would end up over-limiting the number of very small segments that can be queued as your limit would have to be small enough to prevent lots of large segments being queued as they would use up too much memory. Perhaps counting the bytes would make most sense, but as our pbufs are the resource it's trying to prevent being entirely consumed by the send queue, I'm happy to leave it as it is. Are you seeing a real problem, or just curious about why it's like that? Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
