On Sat, May 09, 2020 at 02:51:05PM +0100, Russell King - ARM Linux admin wrote:
> On Sat, May 09, 2020 at 03:14:05PM +0200, Matteo Croce wrote:
> > On Sat, May 9, 2020 at 1:45 PM Russell King - ARM Linux admin
> > <li...@armlinux.org.uk> wrote:
> > >
> > > On Sat, May 09, 2020 at 11:15:58AM +0000, Stefan Chulski wrote:
> > > >
> > > >
> > > > > -----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
> > > > >
> > > > > 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".
> > >
> > > Hmm, I'm not sure this is the right way forward. This patch has the
> > > effect of disabling:
> > >
> > > d33ec4525007 ("net: mvpp2: add an RSS classification step for each flow")
> > >
> > > but the commit you're pointing at which caused the regression is:
> > >
> > > 895586d5dc32 ("net: mvpp2: cls: Use RSS contexts to handle RSS tables")
> > >
> > >
> >
> > Hi,
> >
> > When git bisect pointed to 895586d5dc32 ("net: mvpp2: cls: Use RSS
> > contexts to handle RSS tables"), which was merged
> > almost an year after d33ec4525007 ("net: mvpp2: add an RSS
> > classification step for each flow"), so I assume that between these
> > two commits either the feature was working or it was disable and we
> > didn't notice
> >
> > Without knowing what was happening, which commit should my Fixes tag point
> > to?
>
> Let me make sure that I get this clear:
>
> - Prior to 895586d5dc32, you can turn on and off rxhash without issue
> on any port.
> - After 895586d5dc32, turning rxhash on eth2 prevents reception.
>
> Prior to 895586d5dc32, with rxhash on, it looks like hashing using
> CRC32 is supported but only one context. So, if it's possible to
> enable rxhash on any port on the mcbin without 895586d5dc32, and the
> port continues to work, I'd say the bug was introduced by
> 895586d5dc32.
>
> Of course, that would be reinforced if there was a measurable
> difference in performance due to rxhash on each port.
I've just run this test, but I can detect no difference in performance
with or without 895586d5dc32 on eth0 or eth2 on the mcbin (apart from
eth2 stopping working with 895586d5dc32 applied.) I tested this by
reverting almost all changes to the mvpp2 driver between 5.6 and that
commit.
That's not too surprising; I'm using my cex7 platform with the Mellanox
card in for one end of the 10G link, and that platform doesn't seem to
be able to saturdate a 10G link - it only seems to manage around 4Gbps.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
