Re: [lwip-users] snd_queuelen does not count the number of segments...

[Tom Hennen]

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 <address@hidden> 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
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users