[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240103173347.GA72773@kernel.org>
Date: Wed, 3 Jan 2024 17:33:47 +0000
From: Simon Horman <horms@...nel.org>
To: Gerhard Engleder <gerhard@...leder-embedded.com>
Cc: ahmed.zaki@...el.com, netdev@...r.kernel.org, davem@...emloft.net,
kuba@...nel.org, edumazet@...gle.com, pabeni@...hat.com,
Jeff Guo <jia.guo@...el.com>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Tony Nguyen <anthony.l.nguyen@...el.com>
Subject: Re: [PATCH net-next] Revert "net: ethtool: add support for
symmetric-xor RSS hash"
On Sun, Dec 24, 2023 at 11:03:29PM +0100, Gerhard Engleder wrote:
> On 24.12.23 21:54, Simon Horman wrote:
> > + Jeff Guo <jia.guo@...el.com>
> > Jesse Brandeburg <jesse.brandeburg@...el.com>
> > Tony Nguyen <anthony.l.nguyen@...el.com>
> >
> > On Fri, Dec 22, 2023 at 10:00:00PM +0100, Gerhard Engleder wrote:
> > > This reverts commit 13e59344fb9d3c9d3acd138ae320b5b67b658694.
> > >
> > > The tsnep driver and at least also the macb driver implement the ethtool
> > > operation set_rxnfc but not the get_rxfh operation. With this commit
> > > set_rxnfc returns -EOPNOTSUPP if get_rxfh is not implemented. This renders
> > > set_rxnfc unuseable for drivers without get_rxfh.
> > >
> > > Make set_rxfnc working again for drivers without get_rxfh by reverting
> > > that commit.
> > >
> > > Signed-off-by: Gerhard Engleder <gerhard@...leder-embedded.com>
> >
> > Hi Gerhard,
> >
> > I think it would be nice to find a way forwards that resolved
> > the regression without reverting the feature. But, if that doesn't work
> > out, I think the following two patches need to be reverted first in
> > order to avoid breaking (x86_64 allmodconfig) builds.
> >
> > 352e9bf23813 ("ice: enable symmetric-xor RSS for Toeplitz hash function")
> > 4a3de3fb0eb6 ("iavf: enable symmetric-xor RSS for Toeplitz hash function")
>
> Hi Simon,
>
> frist I thought about fixing, but then I was afraid that the rxfh check in
> ethtool_set_rxnfc() may also affect other drivers with ethtool
> get_rxfh() too. I'm not an expert in that area, so I thought it is not a
> good idea to fix stuff that I don't understand and cannot test.
Understood.
> Taking a second look, rxfh is only checked if RXH_XFRM_SYM_XOR is set and
> this flag is introduced with the same commit. So it should be safe
> to do the rxfh check only if ethtool get_rxfh() is available.
Thanks for taking a second look.
For the record, unless I am mistaken, the revised approach has been
accepted.
Link: https://lore.kernel.org/all/20231226205536.32003-1-gerhard@engleder-embedded.com/
Powered by blists - more mailing lists