[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20200211075442.0de80458@hermes.lan>
Date: Tue, 11 Feb 2020 07:54:42 -0800
From: Stephen Hemminger <stephen@...workplumber.org>
To: netdev@...r.kernel.org
Subject: Fw: [Bug 206497] New: pfifo_fast: netdev xmit sends frames OOO to
devices
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@...zilla.kernel.org
To: stephen@...workplumber.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@...workplumber.org
Reporter: chaitanya.mgit@...il.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.
Powered by blists - more mailing lists