tcp and pbuf_queue

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

tcp and pbuf_queue

Tom Hennen
In my link layer driver I'm queuing packets to be transmitted using pbuf_queue (using pbuf_take when appropriate)
 
There are some times when the link layer driver can't transmit packets for a few seconds (it's busy doing something else).
 
This seems to be long enough for TCP packets to timeout and be retransmitted. 
When they are retransmitted the same pbufs are given to the link layer driver; which has not yet transmitted the first set of packets.
 
When the link layer then uses pbuf_queue to put them on the packet queue there is an assertion because the first packet on the queue is the same as the packet being added (since the link layer didn't actually *send* the packets TCP gave it earlier).
 
It seems my options are
  • Check the queue before adding the new packet, don't add duplicate packets
  • Check the queue before adding the new packet, if a duplicate is found make a copy of the new packet and queue that
  • Somehow disable TCP timeouts and retransmissions when the link layer isn't sending packets
  • Some other method?
What is the best way to avoid this problem?
 
Thanks,
 
Tom Hennen

_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: tcp and pbuf_queue

Kieran Mansley
On Fri, Nov 17, 2006 at 02:51:46PM -0500, Tom Hennen wrote:
> It seems my options are
>
>   - Check the queue before adding the new packet, don't add duplicate
>   packets
>   - Check the queue before adding the new packet, if a duplicate is
>   found make a copy of the new packet and queue that
>   - Somehow disable TCP timeouts and retransmissions when the link layer
>   isn't sending packets
>   - Some other method?

Your first suggestion should work and be quite easy to implement, but
the stack will still think it needed to retransmit and adjust TCPs
parameters accordingly.  This may impact your performance.  If you can
find a way to avoid such long delays, that would be best.

To do the job in the stack itself would require us to tag each packet
with a flag that says "I've sent this to the hardware" and it would
then not retransmit that packet until the hardware (or device driver
or whatever) had cleared the flag to indicate it had actually been
sent and was no longer queued.


Kieran


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: tcp and pbuf_queue

Tom Hennen
Yeah, I think I'll go with just not adding the packets to the queue.  To do it 'right' seems to require quite a lot of work, and I'm not entirely sure the TCP stack shouldn't back-off.  One might be able to argue that this delay is a form of congestion after all.
 
Thanks for your input.
 
Tom

 
On 11/19/06, Kieran Mansley <[hidden email]> wrote:
On Fri, Nov 17, 2006 at 02:51:46PM -0500, Tom Hennen wrote:
> It seems my options are
>
>   - Check the queue before adding the new packet, don't add duplicate
>   packets
>   - Check the queue before adding the new packet, if a duplicate is
>   found make a copy of the new packet and queue that
>   - Somehow disable TCP timeouts and retransmissions when the link layer
>   isn't sending packets
>   - Some other method?

Your first suggestion should work and be quite easy to implement, but
the stack will still think it needed to retransmit and adjust TCPs
parameters accordingly.  This may impact your performance.  If you can
find a way to avoid such long delays, that would be best.

To do the job in the stack itself would require us to tag each packet
with a flag that says "I've sent this to the hardware" and it would
then not retransmit that packet until the hardware (or device driver
or whatever) had cleared the flag to indicate it had actually been
sent and was no longer queued.


Kieran


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users