On Sat, May 09, 2020 at 04:15:46PM +0200, Matteo Croce wrote:
> Currently rxhash only works on the first port of the CP (Communication
> Processor). Enabling it on other ports completely blocks packet reception.
> This patch only adds rxhash as supported feature to the first port,
> so rxhash can't be enabled on other ports:
>
> # ethtool -K eth0 rxhash on
> # ethtool -K eth1 rxhash on
> # ethtool -K eth2 rxhash on
> Cannot change receive-hashing
> Could not change any device features
> # ethtool -K eth3 rxhash on
> Cannot change receive-hashing
> Could not change any device features
>
> Fixes: 895586d5dc32 ("net: mvpp2: cls: Use RSS contexts to handle RSS tables")
> Signed-off-by: Matteo Croce <mcr...@redhat.com>
> ---
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 2b5dad2ec650..ba71583c7ae3 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -5423,7 +5423,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->id == 0)
> + dev->hw_features |= NETIF_F_RXHASH;
> dev->features |= NETIF_F_NTUPLE;
> }
I seem to have discovered the cause of the problem in the old thread,
so I suggest we wait and see whether anyone offers up a proper
solution to this regression before we rush to completely disable
this feature.
I would suggest with a high degress of confidence based on my
research that prior to the offending commit (895586d5dc32), rx
hashing was working fine, distributing interrupts across the cores.
--
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
