kernel.git/net/ipv4/tcp_input.c, branch linux-2.6.28.y

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2008-10-08T21:56:41Z

Conflicts: drivers/net/e1000e/ich8lan.c drivers/net/e1000e/netdev.c

tcp: Fix possible double-ack w/ user dma

2008-10-07T22:31:19Z

From: Ali Saidi When TCP receive copy offload is enabled it's possible that tcp_rcv_established() will cause two acks to be sent for a single packet. In the case that a tcp_dma_early_copy() is successful, copied_early is set to true which causes tcp_cleanup_rbuf() to be called early which can send an ack. Further along in tcp_rcv_established(), __tcp_ack_snd_check() is called and will schedule a delayed ACK. If no packets are processed before the delayed ack timer expires the packet will be acked twice. Signed-off-by: David S. Miller

tcp: cleanup messy initializer

2008-10-07T21:43:31Z

I'm quite sure that if I give this function in its old format for you to inspect, you start to wonder what is the type of demanded or if it's a global variable. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller

tcp: kill pointless urg_mode

2008-10-07T21:43:06Z

It all started from me noticing that this urgent check in tcp_clean_rtx_queue is unnecessarily inside the loop. Then I took a longer look to it and found out that the users of urg_mode can trivially do without, well almost, there was one gotcha. Bonus: those funny people who use urg with >= 2^31 write_seq - snd_una could now rejoice too (that's the only purpose for the between being there, otherwise a simple compare would have done the thing). Not that I assume that the rest of the tcp code happily lives with such mind-boggling numbers :-). Alas, it turned out to be impossible to set wmem to such numbers anyway, yes I really tried a big sendfile after setting some wmem but nothing happened :-). ...Tcp_wmem is int and so is sk_sndbuf... So I hacked a bit variable to long and found out that it seems to work... :-) Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller

tcp: Fix queue traversal in tcp_use_frto().

2008-09-23T09:51:41Z

We must check tcp_skb_is_last() before doing a tcp_write_queue_next(). Signed-off-by: David S. Miller

net: Remove __skb_insert() calls outside of skbuff internals.

2008-09-22T04:28:51Z

This minor cleanup simplifies later changes which will convert struct sk_buff and friends over to using struct list_head. Signed-off-by: David S. Miller

tcp: don't clear lost_skb_hint when not necessary

2008-09-21T04:25:52Z

Most importantly avoid doing it with cumulative ACK. However, since we have lost_cnt_hint in the picture as well needing adjustments, it's not as trivial as dealing with retransmit_skb_hint (and cannot be done in the all place we could trivially leave retransmit_skb_hint untouched). With the previous patch, this should mostly remove O(n^2) behavior while cumulative ACKs start flowing once rexmit after a lossy round-trip made it through. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller

tcp: don't clear retransmit_skb_hint when not necessary

2008-09-21T04:25:15Z

Most importantly avoid doing it with cumulative ACK. Not clearing means that we no longer need n^2 processing in resolution of each fast recovery. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller

tcp: No need to clear retransmit_skb_hint when SACKing

2008-09-21T04:21:16Z

Because lost counter no longer requires tuning, this is trivial to remove (the tuning wouldn't have been too hard either) because no "new" retransmittable skb appeared below retransmit_skb_hint when SACKing for sure. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller

tcp: Kill precaution that's very likely obsolete

2008-09-21T04:20:50Z

I suspect it might have been related to the changed amount of lost skbs, which was counted by retransmit_cnt_hint that got changed. The place for this clearing was very illogical anyway, it should have been after the LOST-bit clearing loop to make any sense. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller