> -----Original Message----- > From: Matteo Croce <mcr...@redhat.com> > Sent: Saturday, May 9, 2020 3:13 AM > To: David S . Miller <da...@davemloft.net> > Cc: Maxime Chevallier <maxime.chevall...@bootlin.com>; netdev > <netdev@vger.kernel.org>; LKML <linux-ker...@vger.kernel.org>; Antoine > Tenart <antoine.ten...@bootlin.com>; Thomas Petazzoni > <thomas.petazz...@bootlin.com>; gregory.clem...@bootlin.com; > miquel.ray...@bootlin.com; Nadav Haklai <nad...@marvell.com>; Stefan > Chulski <stef...@marvell.com>; Marcin Wojtas <m...@semihalf.com>; Linux > ARM <linux-arm-ker...@lists.infradead.org>; Russell King - ARM Linux admin > <li...@armlinux.org.uk> > Subject: [EXT] Re: [PATCH net-next 3/5] net: mvpp2: cls: Use RSS contexts to > handle RSS tables > > External Email > > ---------------------------------------------------------------------- > On Thu, Apr 23, 2020 at 7:00 PM Russell King - ARM Linux admin > <li...@armlinux.org.uk> wrote: > > > > On Tue, Apr 14, 2020 at 01:43:02AM +0200, Matteo Croce wrote: > > > On Tue, Apr 14, 2020 at 1:21 AM Maxime Chevallier > > > <maxime.chevall...@bootlin.com> wrote: > > > > > > > > The PPv2 controller has 8 RSS tables that are shared across all > > > > ports on a given PPv2 instance. The previous implementation > > > > allocated one table per port, leaving others unused. > > > > > > > > By using RSS contexts, we can make use of multiple RSS tables per > > > > port, one being the default table (always id 0), the other ones > > > > being used as destinations for flow steering, in the same way as rx > > > > rings. > > > > > > > > This commit introduces RSS contexts management in the PPv2 driver. > > > > We always reserve one table per port, allocated when the port is probed. > > > > > > > > The global table list is stored in the struct mvpp2, as it's a > > > > global resource. Each port then maintains a list of indices in > > > > that global table, that way each port can have it's own numbering > > > > scheme starting from 0. > > > > > > > > One limitation that seems unavoidable is that the hashing > > > > parameters are shared across all RSS contexts for a given port. > > > > Hashing parameters for ctx 0 will be applied to all contexts. > > > > > > > > Signed-off-by: Maxime Chevallier <maxime.chevall...@bootlin.com> > > > > > > Hi all, > > > > > > I noticed that enabling rxhash blocks the RX on my Macchiatobin. It > > > works fine with the 10G ports (the RX rate goes 4x up) but it > > > completely kills the gigabit interface. > > > > > > # 10G port > > > root@macchiatobin:~# iperf3 -c 192.168.0.2 Connecting to host > > > 192.168.0.2, port 5201 [ 5] local 192.168.0.1 port 42394 connected > > > to 192.168.0.2 port 5201 > > > [ ID] Interval Transfer Bitrate Retr Cwnd > > > [ 5] 0.00-1.00 sec 941 MBytes 7.89 Gbits/sec 4030 250 KBytes > > > [ 5] 1.00-2.00 sec 933 MBytes 7.82 Gbits/sec 4393 240 KBytes > > > root@macchiatobin:~# ethtool -K eth0 rxhash on root@macchiatobin:~# > > > iperf3 -c 192.168.0.2 Connecting to host 192.168.0.2, port 5201 [ > > > 5] local 192.168.0.1 port 42398 connected to 192.168.0.2 port 5201 > > > [ ID] Interval Transfer Bitrate Retr Cwnd > > > [ 5] 0.00-1.00 sec 860 MBytes 7.21 Gbits/sec 428 410 KBytes > > > [ 5] 1.00-2.00 sec 859 MBytes 7.20 Gbits/sec 185 563 KBytes > > > > > > # gigabit port > > > root@macchiatobin:~# iperf3 -c turbo Connecting to host turbo, port > > > 5201 [ 5] local 192.168.85.42 port 45144 connected to 192.168.85.6 > > > port 5201 > > > [ ID] Interval Transfer Bitrate Retr Cwnd > > > [ 5] 0.00-1.00 sec 113 MBytes 948 Mbits/sec 0 407 KBytes > > > [ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec 0 428 KBytes > > > root@macchiatobin:~# ethtool -K eth2 rxhash on root@macchiatobin:~# > > > iperf3 -c turbo > > > iperf3: error - unable to connect to server: Resource temporarily > > > unavailable > > > > > > I've bisected and it seems that this commit causes the issue. I > > > tried to revert it on nex-next as a second test, but the code has > > > changed a lot much since, generating too much conflicts. > > > Can you have a look into this? > > > > This behaviour on eth2 is confirmed here on v5.6. Turning on rxhash > > appears to prevent eth2 working. > > > > Maxime, please look into this regression, thanks. > > > > -- > > RMK's Patch system: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.armlinux.org. > > > uk_developer_patches_&d=DwIBaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=DDQ3dK > wkTIxK > > Al6_Bs7GMx4zhJArrXKN2mDMOXGh7lg&m=ntT7WKmzla65VWVPZMCr2- > 8bTGq4cXdJ1RRL > > gqFkmUc&s=jhKRohlyU0XtX0U0Rjt6XvJgMKLy_HedaFVSJwGYuD8&e= > > FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down > > 587kbps up > > > > Hi, > > What do you think about temporarily disabling it like this? > > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c > @@ -5775,7 +5775,8 @@ static int mvpp2_port_probe(struct platform_device > *pdev, > NETIF_F_HW_VLAN_CTAG_FILTER; > > if (mvpp22_rss_is_supported()) { > - dev->hw_features |= NETIF_F_RXHASH; > + if (port->phy_interface != PHY_INTERFACE_MODE_SGMII) > + dev->hw_features |= NETIF_F_RXHASH; > dev->features |= NETIF_F_NTUPLE; > } > > > David, is this "workaround" too bad to get accepted?
Not sure that RSS related to physical interface(SGMII), better just remove NETIF_F_RXHASH as "workaround". Stefan.