netdev - Fw: [Bug 199823] New: HTB not honoring Queue priority when being overdriven with large limits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20180525084546.7df48952@xeon-e3>
Date:   Fri, 25 May 2018 08:45:46 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     netdev@...r.kernel.org
Subject: Fw: [Bug 199823] New: HTB not honoring Queue priority when being
 overdriven with large limits

Looks like a TSO issue?

Begin forwarded message:

Date: Thu, 24 May 2018 16:40:26 +0000
From: bugzilla-daemon@...zilla.kernel.org
To: stephen@...workplumber.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: stephen@...workplumber.org
          Reporter: tyohe@...techefdata.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.