Fw: [Bug 206497] New: pfifo_fast: netdev xmit sends frames OOO to devices

Fw: [Bug 206497] New: pfifo_fast: netdev xmit sends frames OOO to devices

[Stephen Hemminger]

This seems to be a duplicate of recent bug on qdisc ordering.
But forwarded it so that netdev can see it as well.

Begin forwarded message:

Date: Tue, 11 Feb 2020 13:08:19 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 206497] New: pfifo_fast: netdev xmit sends frames OOO to devices


https://bugzilla.kernel.org/show_bug.cgi?id=206497

            Bug ID: 206497
           Summary: pfifo_fast: netdev xmit sends frames OOO to devices
           Product: Networking
           Version: 2.5
    Kernel Version: 5.4.18
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
          Assignee: stephen@networkplumber.org
          Reporter: chaitanya.mgit@gmail.com
        Regression: No

When running iperf3 on a Single Q device (WLAN device), iperf3 reports OOO (out
of order frames) after investigating it was found the ndo_xmit() itself is
sending the frames OOO. (only a few per stream)

$ sudo tc -s qdisc show dev wlp4s0f0
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1
1 1
 Sent 792082458 bytes 523933 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 


4 iperf3 sessions are run on different ports and below rules to prioritize
them:

iptables -A OUTPUT -o lo -t mangle -d localhost -p udp --dport 5201 -j DSCP
--set-dscp-class cs1
iptables -A OUTPUT -o lo -t mangle -d localhost -p udp --dport 5202 -j DSCP
--set-dscp-class cs0
iptables -A OUTPUT -o lo -t mangle -d localhost -p udp --dport 5203 -j DSCP
--set-dscp-class cs4
iptables -A OUTPUT -o lo -t mangle -d localhost -p udp --dport 5204 -j DSCP
--set-dscp-class cs6

FYI, my problem seems to quite similar to the one
https://www.spinics.net/lists/netdev/msg490934.html but the fix is already part
of 5.4.18

2 workarounds found
 - booting with `nosmp` (similar to commenting TCQ_F_NOLOCK but haven't tried)
 - And, switching to fq_codel solves the problem. (Forgot the exact params for
the tc fq_codel)

-- 
You are receiving this mail because:
You are the assignee for the bug.