On Thu, 2015-02-05 at 04:57 -0800, Eric Dumazet wrote: > The intention is to control the queues to the following : > > 1 ms of buffering, but limited to a configurable value. > > On a 40Gbps flow, 1ms represents 5 MB, which is insane. > > We do not want to queue 5 MB of traffic, this would destroy latencies > for all concurrent flows. (Or would require having fq_codel or fq as > packet schedulers, instead of default pfifo_fast) > > This is why having 1.5 ms delay between the transmit and TX completion > is a problem in your case.
Note that TCP stack could detect when this happens, *if* ACK where delivered before the TX completions, or when TX completion happens, we could detect that the clone of the freed packet was freed. In my test, when I did "ethtool -C eth0 tx-usecs 1024 tx-frames 64", and disabling GSO, TCP stack sends a bunch of packets (a bit less than 64), blocks on tcp_limit_output_bytes. Then we receive 2 stretch ACKS after ~50 usec. TCP stack tries to push again some packets but blocks on tcp_limit_output_bytes again. 1ms later, TX completion happens, tcp_wfree() is called, and TCP stack push following ~60 packets. TCP could eventually dynamically adjust the tcp_limit_output_bytes, using a per flow dynamic value, but I would rather not add a kludge in TCP stack only to deal with a possible bug in ath10k driver. niu has a similar issue and simply had to call skb_orphan() : drivers/net/ethernet/sun/niu.c:6669: skb_orphan(skb); -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
