> I think the point is that we should set the probe0 timer even if the
> sending-window is not 0. This should be the timeout that the rfc1122 that
> you quoted yesterday talks about.
Yes and the kernel actually does this. Otherwise we would see much more
stalls. For every incoming ACK it calls tcp_data_snd_check().
This either puts new data on the wire or starts the PROBE0 timer. But
if there is currently no data on the write queue (skb==NULL) the function
does nothing. This is the only case where the stall can happen.
New data arrives via tcp_v4_sendmsg() and for write sizes < mss no
data is put on the wire and the PROBE0 timer is not started.
> What looks to me wrong is that in the queue_it case (the queue_it case
> should deal with resembling iovect in full-mss-sized packets) we are not
> setting the probe0 timer in tcp_send_skb.
Agreed.
>
> So to have always a probe0 timer pending when we are only queueing data I
> think we should do this as you suggested:
>
> Index: tcp_output.c
> ===================================================================
> RCS file: /var/cvs/linux/net/ipv4/tcp_output.c,v
> retrieving revision 1.1.2.12
> diff -u -r1.1.2.12 tcp_output.c
> --- tcp_output.c 1999/03/08 13:27:44 1.1.2.12
> +++ tcp_output.c 1999/03/08 23:30:28
> @@ -177,7 +177,7 @@
> /* Queue it, remembering where we must start sending. */
> if (tp->send_head == NULL)
> tp->send_head = skb;
> - if (!force_queue && tp->packets_out == 0 && !tp->pending) {
> + if (tp->packets_out == 0 && !tp->pending) {
> tp->pending = TIME_PROBE0;
> tcp_reset_xmit_timer(sk, TIME_PROBE0, tp->rto);
> }
>
>
> But I am not 100% sure this is enough to make sure to always have a probe0
> timer pending if there's some data pending not yet transmitted and we are
> waiting for a window update before transmitting data.
Im quite sure. The patch looks fine for me. I actually tried this some
days ago , it fixed the stalls even with the broken cleanup_rbuf()
function.
> Another thing that make me ill ;) is the fact that tcpdump screw up things
> while your proggy is running on the loopback device. Now I am going to
> debug _why_ this happens.
I have the same problem with tcpdump on lo. It shows not all frames.
Matthias
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/