Le mercredi 14 décembre 2011 à 18:12 -0800, Vijay Subramanian a écrit : > On 14 December 2011 11:27, Rick Jones <[email protected]> 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.
