tcpdump mailing list archives
Re: twice past the taps, thence out to net?
From: Eric Dumazet <eric.dumazet () gmail com>
Date: Thu, 15 Dec 2011 18:43:18 +0100
Le mercredi 14 décembre 2011 à 18:12 -0800, Vijay Subramanian a écrit :
On 14 December 2011 11:27, Rick Jones <rick.jones2 () hp com> wrote:While looking at "something else" with tcpdump/tcptrace, tcptrace emitted lots of notices about hardware duplicated packets being detected (same TCP sequence number and IP datagram ID). Sure enough, if I go into the tcpdump trace (taken on the sender) I can find instances of what it was talking about, separated in time by rather less than I would expect to be the RTO, and often as not with few if any intervening arriving ACKs to trigger anything like fast retransmit. And besides, those would have a different IP datagram ID no? I did manage to reproduce the issue with plain netperf tcp_stream tests. I had one sending system with 30 concurrent netperf tcp_stream tests to 30 other receiving systems. There are "hardware duplicates" in the sending trace, but no duplicate segments (that I can find thus far) in the two receiver side traces I took. Of course that doesn't mean "conclusively" there were two actual sends but it suggests there werent. While I work through the "obtain permission" path to post the packet traces (don't ask...) I thought I would ask if anyone else has seen something similar. In this case, all the systems are running a 2.6.38-8 Ubuntu kernel (the same sorts of issues which delay my just putting the traces up on netperf.org preclude a later kernel, and I've no other test systems :( ), with Intel 82576 interfaces being driven by: $ sudo ethtool -i eth0 driver: igb version: 2.1.0-k2 firmware-version: 1.8-2 bus-info: 0000:05:00.0 All the systems were connected to the same switch.Rick, This may be of help. http://www.tcptrace.org/faq_ans.html#FAQ%2021
More exactly, we call dev_queue_xmit_nit() from dev_hard_start_xmit() _before_ giving skb to device driver. If device driver returns NETDEV_TX_BUSY, and a qdisc was setup on the device, packet is requeued. Later, when queue is allowed to send again packets, packet is retransmitted (and traced a second time in dev_queue_xmit_nit()) You can see the 'requeues' counter from "tc -s -d qdisc" output : qdisc mq 0: dev eth2 root Sent 29421597369 bytes 20301716 pkt (dropped 0, overlimits 0 requeues 371) backlog 0b 0p requeues 371 - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Current thread:
- twice past the taps, thence out to net? Rick Jones (Dec 14)
- Re: twice past the taps, thence out to net? Benjamin Poirier (Dec 14)
- Re: twice past the taps, thence out to net? Vijay Subramanian (Dec 14)
- Re: twice past the taps, thence out to net? Eric Dumazet (Dec 15)
- Re: twice past the taps, thence out to net? Rick Jones (Dec 15)
- Re: twice past the taps, thence out to net? Eric Dumazet (Dec 15)
- Re: twice past the taps, thence out to net? Stephen Hemminger (Dec 15)
- Message not available
- Re: twice past the taps, thence out to net? Rick Jones (Dec 15)
- Re: twice past the taps, thence out to net? Eric Dumazet (Dec 15)
- Re: twice past the taps, thence out to net? Jesse Brandeburg (Dec 16)
- Re: twice past the taps, thence out to net? Eric Dumazet (Dec 16)
- Re: twice past the taps, thence out to net? Rick Jones (Dec 16)
- Re: twice past the taps, thence out to net? Eric Dumazet (Dec 16)
- Re: twice past the taps, thence out to net? Wyborny, Carolyn (Dec 20)
- Re: twice past the taps, thence out to net? Eric Dumazet (Dec 15)