Looks like a TSO issue? Begin forwarded message:
Date: Thu, 24 May 2018 16:40:26 +0000 From: bugzilla-dae...@bugzilla.kernel.org To: step...@networkplumber.org Subject: [Bug 199823] New: HTB not honoring Queue priority when being overdriven with large limits https://bugzilla.kernel.org/show_bug.cgi?id=199823 Bug ID: 199823 Summary: HTB not honoring Queue priority when being overdriven with large limits Product: Networking Version: 2.5 Kernel Version: 4.9.16 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other Assignee: step...@networkplumber.org Reporter: ty...@comtechefdata.com Regression: No Created attachment 276165 --> https://bugzilla.kernel.org/attachment.cgi?id=276165&action=edit Files needed to recreate problem Our application reads packets from eth2 using pf_ring and outputs them to eth3 by doing raw socket sends to eth3. We have two queues, one at priority 4 for port 3232 traffic, and one at priority 5 at port 3233 traffic. When overdriving the specified max rate of the HTB of 1 Mbps with two 1 Mbps iperf UDP streams, the HTB splits the traffic evenly over the two queues. However it should allow the priority 4 queue to meet its max rate of 1 Mbps and give no traffic to the lower priority queue. If we specify a small byte limit (15000 bytes) to each queue, the shaping works as expected. IE the lower priority queue is completely starved and the higher priority queue can meet its max rate. At higher byte limits the shaping breaks down and traffic is split evenly. When we set up a bridge br0 of eth2 and eth3 and run the same data streams through it, the shaping works correctly regardless of the byte limits. Therefore, we have concluded that the IP stack or bridge module of Linux is marking the packets in such a way that HTB always shapes them correctly. However when doing raw socket sends to the eth3 interface the HTB shaping breaks down. We can recreate this problem with the following kernel versions: 4.16.9, 4.9.90, 3.10.102. This problem can be recreated easily using the "tcpreplay" tool. The steps to recreate are: 1. Setup a Linux box with eth2/eth3 bridge 2. Download and build "tcpreplay-4.2.4.tar.gz" 3. Set up the QoS a) copy attached file "traffic" and "dotraffic" to /tmp b) 'chmod 755 dotraffic' c) './dotraffic' 4. Execute "tcpreplay" using the attached pcap file with the following command: 'tcpreplay -l 1000 -i eth3 -M 155 -K eth2.pcap0' Verify that the problem is recreated by executing the following command: watch 'tc -s -d qdisc show dev eth3' The above command will show that traffic is being split evenly between the two queues instead of honoring the priority. Also in the attachment is a screenshot of the web GUI that shows the status of the queues. Thanks. -- You are receiving this mail because: You are the assignee for the bug.
