[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2662f157-fa92-8a99-473a-9ca5f7887d28@gmail.com>
Date: Wed, 12 Jan 2022 12:31:14 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
UNGLinuxDriver@...rochip.com,
Xiaoliang Yang <xiaoliang.yang_1@....com>
Subject: Re: [PATCH net] net: mscc: ocelot: don't let phylink re-enable TX
PAUSE on the NPI port
On 1/12/22 12:21 PM, Vladimir Oltean wrote:
> Since commit b39648079db4 ("net: mscc: ocelot: disable flow control on
> NPI interface"), flow control should be disabled on the DSA CPU port
> when used in NPI mode.
>
> However, the commit blamed in the Fixes: tag below broke this, because
> it allowed felix_phylink_mac_link_up() to overwrite SYS_PAUSE_CFG_PAUSE_ENA
> for the DSA CPU port.
>
> This issue became noticeable since the device tree update from commit
> 8fcea7be5736 ("arm64: dts: ls1028a: mark internal links between Felix
> and ENETC as capable of flow control").
>
> The solution is to check whether this is the currently configured NPI
> port from ocelot_phylink_mac_link_up(), and to not modify the statically
> disabled PAUSE frame transmission if it is.
>
> When the port is configured for lossless mode as opposed to tail drop
> mode, but the link partner (DSA master) doesn't observe the transmitted
> PAUSE frames, the switch termination throughput is much worse, as can be
> seen below.
>
> Before:
>
> root@...ian:~# iperf3 -c 192.168.100.2
> Connecting to host 192.168.100.2, port 5201
> [ 5] local 192.168.100.1 port 37504 connected to 192.168.100.2 port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 28.4 MBytes 238 Mbits/sec 357 22.6 KBytes
> [ 5] 1.00-2.00 sec 33.6 MBytes 282 Mbits/sec 426 19.8 KBytes
> [ 5] 2.00-3.00 sec 34.0 MBytes 285 Mbits/sec 343 21.2 KBytes
> [ 5] 3.00-4.00 sec 32.9 MBytes 276 Mbits/sec 354 22.6 KBytes
> [ 5] 4.00-5.00 sec 32.3 MBytes 271 Mbits/sec 297 18.4 KBytes
> ^C[ 5] 5.00-5.06 sec 2.05 MBytes 270 Mbits/sec 45 19.8 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-5.06 sec 163 MBytes 271 Mbits/sec 1822 sender
> [ 5] 0.00-5.06 sec 0.00 Bytes 0.00 bits/sec receiver
>
> After:
>
> root@...ian:~# iperf3 -c 192.168.100.2
> Connecting to host 192.168.100.2, port 5201
> [ 5] local 192.168.100.1 port 49470 connected to 192.168.100.2 port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 259 143 KBytes
> [ 5] 1.00-2.00 sec 110 MBytes 920 Mbits/sec 329 144 KBytes
> [ 5] 2.00-3.00 sec 112 MBytes 936 Mbits/sec 255 144 KBytes
> [ 5] 3.00-4.00 sec 110 MBytes 927 Mbits/sec 355 105 KBytes
> [ 5] 4.00-5.00 sec 110 MBytes 926 Mbits/sec 350 156 KBytes
> [ 5] 5.00-6.00 sec 110 MBytes 925 Mbits/sec 305 148 KBytes
> [ 5] 6.00-7.00 sec 110 MBytes 924 Mbits/sec 320 143 KBytes
> [ 5] 7.00-8.00 sec 110 MBytes 925 Mbits/sec 273 97.6 KBytes
> [ 5] 8.00-9.00 sec 109 MBytes 913 Mbits/sec 299 141 KBytes
> [ 5] 9.00-10.00 sec 110 MBytes 922 Mbits/sec 287 146 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 1.08 GBytes 926 Mbits/sec 3032 sender
> [ 5] 0.00-10.00 sec 1.08 GBytes 925 Mbits/sec receiver
Still quite a lot of retries, do you know where they are coming from?
>
> Fixes: de274be32cb2 ("net: dsa: felix: set TX flow control according to the phylink_mac_link_up resolution")
> Reported-by: Xiaoliang Yang <xiaoliang.yang_1@....com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
--
Florian
Powered by blists - more mailing lists