Skip to contentSkip to conversation

twice past the taps, thence out to net?

DISCUSSION Rick Jones 7 participants 15 messages Dec 14, 2011 – Dec 20, 2011

Subsystems (3)
Networking Network drivers Intel Ethernet
lore
Share & tools
lore

Rick Jones

author
#0 lore raw

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.

It is projecting, but given that the interface was fully saturated, and there were 30 concurrent streams making 64K TSO sends, it "feels" like some sort of "go past the packet tap and be captured, find a queue/resource past the tap unavailable, get re-queued above the tap, get captured again when resent" sort of thing.

Where in the Linux stack does the tap used by libpcap 1.1.1 reside?

rick jones

#1 lore raw
Quoted 3 lines · Rick Jones

Where in the Linux stack does the tap used by libpcap 1.1.1 reside?

On transmission it's before tso/gso, via dev_queue_xmit_nit(). Taps are registered in the ptype_all list.

-Benjamin

#2 lore raw
In reply to Rick Jones
Quoted 25 lines · Rick Jones

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:

Quoted 8 lines
$ 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

Regards,
Vijay Subramanian

#3 lore raw
Quoted 32 lines · Vijay Subramanian
Quoted 31 lines · Rick Jones

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
Quoted 6 lines
Quoted 2 lines

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

author
#4 lore raw
Quoted 9 lines

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())

Is this then an unintended consequence bug, or a known feature?

rick

Quoted 5 lines

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

Sure enough:

$ tc -s -d qdisc
qdisc mq 0: dev eth0 root
 Sent 2212158799862 bytes 1938268098 pkt (dropped 0, overlimits 0 
requeues 4975139)
 backlog 0b 0p requeues 4975139

rick jones

#5 lore raw
Quoted 22 lines · On Thu, 15 Dec 2011 10:32:56 -0800 Rick Jones <[email protected]> wrote:
Quoted 9 lines

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())

Is this then an unintended consequence bug, or a known feature?

rick

Quoted 5 lines

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

Sure enough:

Quoted 7 lines
$ tc -s -d qdisc
qdisc mq 0: dev eth0 root
  Sent 2212158799862 bytes 1938268098 pkt (dropped 0, overlimits 0 
requeues 4975139)
  backlog 0b 0p requeues 4975139

rick jones

Device's work better if the driver proactively manages stop_queue/wake_queue. Old devices used TX_BUSY, but newer devices tend to manage the queue themselves.

#6 lore raw
Quoted 31 lines · Stephen Hemminger
Quoted 28 lines · On Thu, 15 Dec 2011 10:32:56 -0800 Rick Jones <[email protected]> wrote:
Quoted 9 lines

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())

Is this then an unintended consequence bug, or a known feature?

rick

Quoted 5 lines

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

Sure enough:

$ tc -s -d qdisc
qdisc mq 0: dev eth0 root
  Sent 2212158799862 bytes 1938268098 pkt (dropped 0, overlimits 0 
requeues 4975139)
  backlog 0b 0p requeues 4975139
Quoted 6 lines
Quoted 1 line

rick jones

Device's work better if the driver proactively manages stop_queue/wake_queue. Old devices used TX_BUSY, but newer devices tend to manage the queue themselves.

Some 'new' drivers like igb can be fooled in case skb is gso segmented ?

Because igb_xmit_frame_ring() needs skb_shinfo(skb)->nr_frags + 4 descriptors, igb should stop its queue not at MAX_SKB_FRAGS + 4, but MAX_SKB_FRAGS*4

drivers/net/ethernet/intel/igb/igb_main.c +1 -1
index 89d576c..989da36 100644
@@ -4370,7 +4370,7 @@ netdev_tx_t igb_xmit_frame_ring(struct sk_buff *skb,
 	igb_tx_map(tx_ring, first, hdr_len);
 
 	/* Make sure there is space in the ring for the next send. */
-	igb_maybe_stop_tx(tx_ring, MAX_SKB_FRAGS + 4);
+	igb_maybe_stop_tx(tx_ring, MAX_SKB_FRAGS * 4);
 
 	return NETDEV_TX_OK;
author
#7 lore raw
Quoted 16 lines · Eric Dumazet
Quoted 4 lines

Device's work better if the driver proactively manages stop_queue/wake_queue. Old devices used TX_BUSY, but newer devices tend to manage the queue themselves.

Some 'new' drivers like igb can be fooled in case skb is gso segmented ?

Because igb_xmit_frame_ring() needs skb_shinfo(skb)->nr_frags + 4 descriptors, igb should stop its queue not at MAX_SKB_FRAGS + 4, but MAX_SKB_FRAGS*4

drivers/net/ethernet/intel/igb/igb_main.c +0 -0
index 89d576c..989da36 100644

drivers/net/ethernet/intel/igb/igb_main.c netdev_tx_t igb_xmit_frame_ring(struct sk_buff *skb, · line 4375

Quoted 7 lines
drivers/net/ethernet/intel/igb/igb_main.c +1 -1
@@ -4370,7 +4370,7 @@ netdev_tx_t igb_xmit_frame_ring(struct sk_buff *skb,
  	igb_tx_map(tx_ring, first, hdr_len);
 
  	/* Make sure there is space in the ring for the next send. */
-	igb_maybe_stop_tx(tx_ring, MAX_SKB_FRAGS + 4);
+	igb_maybe_stop_tx(tx_ring, MAX_SKB_FRAGS * 4);
 
  	return NETDEV_TX_OK;

Is there a minimum transmit queue length here? I get the impression that MAX_SKB_FRAGS is at least 16 and is 18 on a system with 4096 byte pages. The previous addition then would be OK so long as the TX queue was always at least 22 entries in size, but now it would have to always be at least 72?

I guess things are "OK" at the moment:

raj@tardy:~/net-next/drivers/net/ethernet/intel/igb$ grep IGB_MIN_TXD *.[ch]
igb_ethtool.c:	new_tx_count = max_t(u16, new_tx_count, IGB_MIN_TXD);
igb.h:#define IGB_MIN_TXD                       80

but is that getting a little close?

rick jones

#8 lore raw
Quoted 34 lines · Rick Jones
Quoted 16 lines · Eric Dumazet
Quoted 4 lines

Device's work better if the driver proactively manages stop_queue/wake_queue. Old devices used TX_BUSY, but newer devices tend to manage the queue themselves.

Some 'new' drivers like igb can be fooled in case skb is gso segmented ?

Because igb_xmit_frame_ring() needs skb_shinfo(skb)->nr_frags + 4 descriptors, igb should stop its queue not at MAX_SKB_FRAGS + 4, but MAX_SKB_FRAGS*4

drivers/net/ethernet/intel/igb/igb_main.c +0 -0
index 89d576c..989da36 100644

drivers/net/ethernet/intel/igb/igb_main.c netdev_tx_t igb_xmit_frame_ring(struct sk_buff *skb, · line 4375

Quoted 7 lines
drivers/net/ethernet/intel/igb/igb_main.c +1 -1
@@ -4370,7 +4370,7 @@ netdev_tx_t igb_xmit_frame_ring(struct sk_buff *skb,
  	igb_tx_map(tx_ring, first, hdr_len);
 
  	/* Make sure there is space in the ring for the next send. */
-	igb_maybe_stop_tx(tx_ring, MAX_SKB_FRAGS + 4);
+	igb_maybe_stop_tx(tx_ring, MAX_SKB_FRAGS * 4);
 
  	return NETDEV_TX_OK;

Is there a minimum transmit queue length here? I get the impression that MAX_SKB_FRAGS is at least 16 and is 18 on a system with 4096 byte pages. The previous addition then would be OK so long as the TX queue was always at least 22 entries in size, but now it would have to always be at least 72?

I guess things are "OK" at the moment:

Quoted 7 lines
raj@tardy:~/net-next/drivers/net/ethernet/intel/igb$ grep IGB_MIN_TXD *.[ch]
igb_ethtool.c:	new_tx_count = max_t(u16, new_tx_count, IGB_MIN_TXD);
igb.h:#define IGB_MIN_TXD                       80

but is that getting a little close?

rick jones

Sure !

I only pointed out a possible problem, and not gave a full patch, since we also need to change the opposite threshold (when we XON the queue at TX completion)

You can see its not even consistent with the minimum for a single TSO frame ! Most probably your high requeue numbers come from this too low value given the real requirements of the hardware (4 + nr_frags descriptors per skb)

/* How many Tx Descriptors do we need to call netif_wake_queue ? */
#define IGB_TX_QUEUE_WAKE 16

Maybe we should CC Intel guys

Could you try following patch ?

Thanks !

drivers/net/ethernet/intel/igb/igb.h +7 -4
index c69feeb..93ce118 100644
@@ -51,8 +51,8 @@ struct igb_adapter;
 /* TX/RX descriptor defines */
 #define IGB_DEFAULT_TXD                  256
 #define IGB_DEFAULT_TX_WORK		 128
-#define IGB_MIN_TXD                       80
-#define IGB_MAX_TXD                     4096
+#define IGB_MIN_TXD		max_t(unsigned, 80U, IGB_TX_QUEUE_WAKE * 2)
+#define IGB_MAX_TXD             4096
 
 #define IGB_DEFAULT_RXD                  256
 #define IGB_MIN_RXD                       80

@@ -121,8 +121,11 @@ struct vf_data_storage {
 #define IGB_RXBUFFER_16384 16384
 #define IGB_RX_HDR_LEN     IGB_RXBUFFER_512
 
-/* How many Tx Descriptors do we need to call netif_wake_queue ? */
-#define IGB_TX_QUEUE_WAKE	16
+/* How many Tx Descriptors should be available
+ * before calling netif_wake_subqueue() ?
+ */
+#define IGB_TX_QUEUE_WAKE	(MAX_SKB_FRAGS * 4)
+
 /* How many Rx Buffers do we bundle into one write to the hardware ? */
 #define IGB_RX_BUFFER_WRITE	16	/* Must be power of 2 */
#9 lore raw
Quoted 7 lines · Eric Dumazet
Quoted 6 lines · Rick Jones
Quoted 5 lines · Eric Dumazet
Quoted 4 lines

Device's work better if the driver proactively manages stop_queue/wake_queue. Old devices used TX_BUSY, but newer devices tend to manage the queue themselves.

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

Some 'new' drivers like igb can be fooled in case skb is gso segmented ?

Because igb_xmit_frame_ring() needs skb_shinfo(skb)->nr_frags + 4 descriptors, igb should stop its queue not at MAX_SKB_FRAGS + 4, but MAX_SKB_FRAGS*4

can you please help me understand the need for MAX_SKB_FRAGS * 4 as the requirement? Currently driver uses logic like

in hard_start_tx: hey I just finished a tx, I should stop the qdisc if I don't have room (in tx descriptors) for a worst case transmit skb (MAX_SKB_FRAGS + 4) the next time I'm called.
when cleaning from interrupt: My cleanup is done, do I have enough free tx descriptors (should be MAX_SKB_FRAGS + 4) for a worst case transmit? If yes, restart qdisc.

I'm missing the jump from the above logic to using MAX_SKB_FRAGS * 4 (== (18 * 4) == 72) as the minimum number of descriptors I need for a worst case TSO. Each descriptor can point to up to 16kB of contiguous memory, typically we use 1 for offload context setup, 1 for skb->data, and 1 for each page. I think we may be overestimating with MAX_SKB_FRAGS + 4, but that should be no big deal.

#10 lore raw
Quoted 24 lines · Jesse Brandeburg
Quoted 7 lines · Eric Dumazet
Quoted 6 lines · Rick Jones
Quoted 5 lines · Eric Dumazet
Quoted 4 lines

Device's work better if the driver proactively manages stop_queue/wake_queue. Old devices used TX_BUSY, but newer devices tend to manage the queue themselves.

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

Some 'new' drivers like igb can be fooled in case skb is gso segmented ?

Because igb_xmit_frame_ring() needs skb_shinfo(skb)->nr_frags + 4 descriptors, igb should stop its queue not at MAX_SKB_FRAGS + 4, but MAX_SKB_FRAGS*4

can you please help me understand the need for MAX_SKB_FRAGS * 4 as the requirement? Currently driver uses logic like

in hard_start_tx: hey I just finished a tx, I should stop the qdisc if I don't have room (in tx descriptors) for a worst case transmit skb (MAX_SKB_FRAGS + 4) the next time I'm called.
when cleaning from interrupt: My cleanup is done, do I have enough free tx descriptors (should be MAX_SKB_FRAGS + 4) for a worst case transmit? If yes, restart qdisc.

Quoted 6 lines

I'm missing the jump from the above logic to using MAX_SKB_FRAGS * 4 (== (18 * 4) == 72) as the minimum number of descriptors I need for a worst case TSO. Each descriptor can point to up to 16kB of contiguous memory, typically we use 1 for offload context setup, 1 for skb->data, and 1 for each page. I think we may be overestimating with MAX_SKB_FRAGS + 4, but that should be no big deal.

Did you read my second patch ?

Problem is you wakeup the queue too soon (16 available descriptors, while a full TSO packet needs more than that)

How would you explain high 'requeues' number if it was not the problem ?

Also, its suboptimal to wakeup the queue if available space is very low, since only _one_ packet may be dequeued from qdisc (you pay high cost in cache line bouncing)

My first patch was about a very rare event : A full TSO packet is segmented in gso_segment() [ say if you dynamically disable sg on eth device and an old tcp buffer is retransmitted ] : You end with 16 skbs delivered to NIC : In this case we can hit tx ring limit at 4th or 5th skb, and Rick complains tcpdump outputs some packets several times ;)

Since igb needs 4 descriptors for linear skb, I said : 4 * MAX_SKB_FRAGS, but real problem is addressed in my second patch, I believe ?

author
#11 lore raw
In reply to Eric Dumazet
Quoted 16 lines
Quoted 4 lines

but is that getting a little close?

rick jones

Sure !

I only pointed out a possible problem, and not gave a full patch, since we also need to change the opposite threshold (when we XON the queue at TX completion)

You can see its not even consistent with the minimum for a single TSO frame ! Most probably your high requeue numbers come from this too low value given the real requirements of the hardware (4 + nr_frags descriptors per skb)

Quoted 7 lines

/* How many Tx Descriptors do we need to call netif_wake_queue ? */
#define IGB_TX_QUEUE_WAKE 16

Maybe we should CC Intel guys

Could you try following patch ?

I would *love* to. All my accessible igb-driven hardware is in an environment locked to the kernels already there :( Not that it makes it more possible for me to do it, but I suspect it does not require 30 receivers to reproduce the dups with netperf TCP_STREAM. Particularly if the tx queue len is at 256 it may only take 6 or 8. In fact let me try that now...

Yep, with just 8 destinations/concurrent TCP_STREAM tests from the one system one can still see the duplicates in the packet trace taken on the sender.

Perhaps we can trouble the Intel guys to try to reproduce what I've seen?

rick

Quoted 38 lines

Thanks !

drivers/net/ethernet/intel/igb/igb.h +7 -5
index c69feeb..93ce118 100644
@@ -51,8 +51,8 @@ struct igb_adapter;
  /* TX/RX descriptor defines */
  #define IGB_DEFAULT_TXD                  256
  #define IGB_DEFAULT_TX_WORK		 128
-#define IGB_MIN_TXD                       80
-#define IGB_MAX_TXD                     4096
+#define IGB_MIN_TXD		max_t(unsigned, 80U, IGB_TX_QUEUE_WAKE * 2)
+#define IGB_MAX_TXD             4096
 
  #define IGB_DEFAULT_RXD                  256
  #define IGB_MIN_RXD                       80

@@ -121,8 +121,11 @@ struct vf_data_storage {
  #define IGB_RXBUFFER_16384 16384
  #define IGB_RX_HDR_LEN     IGB_RXBUFFER_512
 
-/* How many Tx Descriptors do we need to call netif_wake_queue ? */
-#define IGB_TX_QUEUE_WAKE	16
+/* How many Tx Descriptors should be available
+ * before calling netif_wake_subqueue() ?
+ */
+#define IGB_TX_QUEUE_WAKE	(MAX_SKB_FRAGS * 4)
+
  /* How many Rx Buffers do we bundle into one write to the hardware ? */
  #define IGB_RX_BUFFER_WRITE	16	/* Must be power of 2 */
 
 
 
--

To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#12 lore raw
Quoted 7 lines · Rick Jones

I would *love* to. All my accessible igb-driven hardware is in an environment locked to the kernels already there :( Not that it makes it more possible for me to do it, but I suspect it does not require 30 receivers to reproduce the dups with netperf TCP_STREAM. Particularly if the tx queue len is at 256 it may only take 6 or 8. In fact let me try that now...

Quoted 6 lines

Yep, with just 8 destinations/concurrent TCP_STREAM tests from the one system one can still see the duplicates in the packet trace taken on the sender.

Perhaps we can trouble the Intel guys to try to reproduce what I've seen?

I do have an igb card somewhere (in fact two dual ports), I'll do the test myself !

Thanks

#13 lore raw
Quoted 34 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Eric Dumazet
Sent: Friday, December 16, 2011 11:45 AM
To: Rick Jones
Cc: Stephen Hemminger; Vijay Subramanian; tcpdump- [email protected]; [email protected]; Vick, Matthew; Kirsher, Jeffrey T
Subject: Re: twice past the taps, thence out to net?

Quoted 2 lines · Rick Jones

I would *love* to. All my accessible igb-driven hardware is in an environment locked to the kernels already there :( Not that it makes

it

Quoted 7 lines

more possible for me to do it, but I suspect it does not require 30 receivers to reproduce the dups with netperf TCP_STREAM. Particularly if the tx queue len is at 256 it may only take 6 or 8. In fact let me try that now...

Yep, with just 8 destinations/concurrent TCP_STREAM tests from the one system one can still see the duplicates in the packet trace taken on

the

Quoted 3 lines

sender.

Perhaps we can trouble the Intel guys to try to reproduce what I've

seen?

Quoted 1 line

I do have an igb card somewhere (in fact two dual ports), I'll do the test myself !

Quoted 7 lines

Thanks

--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Let me know if I can do anything to assist. Sorry to have overlooked this thread for a bit.

Thanks,

Carolyn

Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation

#14 lore raw
In reply to Rick Jones
Quoted 11 lines · Rick Jones
Quoted 8 lines

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())

Is this then an unintended consequence bug, or a known feature?

Its a well known feature, some people attempted to remove it ;)

http://answers.softpicks.net/answers/topic/-PATCH-tcpdump-may-trace-some-outbound-packets-twice--2204640-1.htm