[PATCH net-next] ethtool: Fix set RXFH for drivers without RXFH fields support

[PATCH net-next] ethtool: Fix set RXFH for drivers without RXFH fields support

[Gal Pressman]

Some drivers (e.g., mlx4_en) support ->set_rxfh() functionality (such as
setting hash function), but not setting the RXFH fields.

The requirement of ->get_rxfh_fields() in ethtool_set_rxfh() is there to
verify that we have no conflict with the RSS fields options, if it
doesn't exist then there is no point in doing the check.
Soften the check in ethtool_set_rxfh() so it doesn't fail when
->get_rxfh_fields() doesn't exist.

This fixes the following error:
$ ethtool --set-rxfh-indir eth2 hfunc xor
Cannot set RX flow hash configuration: Operation not supported

Fixes: 72792461c8e8 ("net: ethtool: don't mux RXFH via rxnfc callbacks")
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Gal Pressman <gal@nvidia.com>
---
 net/ethtool/ioctl.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index b6d96e562c9a..4bb8bf20a0eb 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -1519,7 +1519,7 @@ static noinline_for_stack int ethtool_set_rxfh(struct net_device *dev,
 	u8 *rss_config;
 	int ret;
 
-	if (!ops->get_rxnfc || !ops->get_rxfh_fields || !ops->set_rxfh)
+	if (!ops->get_rxnfc || !ops->set_rxfh)
 		return -EOPNOTSUPP;
 
 	if (ops->get_rxfh_indir_size)
@@ -1623,9 +1623,11 @@ static noinline_for_stack int ethtool_set_rxfh(struct net_device *dev,
 
 	mutex_lock(&dev->ethtool->rss_lock);
 
-	ret = ethtool_check_flow_types(dev, rxfh.input_xfrm);
-	if (ret)
-		goto out_unlock;
+	if (ops->get_rxfh_fields) {
+		ret = ethtool_check_flow_types(dev, rxfh.input_xfrm);
+		if (ret)
+			goto out_unlock;
+	}
 
 	if (rxfh.rss_context && rxfh_dev.rss_delete) {
 		ret = ethtool_check_rss_ctx_busy(dev, rxfh.rss_context);
-- 
2.40.1

Re: [PATCH net-next] ethtool: Fix set RXFH for drivers without RXFH fields support

[Jakub Kicinski]

On Wed, 9 Jul 2025 18:32:51 +0300 Gal Pressman wrote:
> Some drivers (e.g., mlx4_en) support ->set_rxfh() functionality (such as
> setting hash function), but not setting the RXFH fields.
> 
> The requirement of ->get_rxfh_fields() in ethtool_set_rxfh() is there to
> verify that we have no conflict with the RSS fields options, if it
> doesn't exist then there is no point in doing the check.
> Soften the check in ethtool_set_rxfh() so it doesn't fail when
> ->get_rxfh_fields() doesn't exist.  
> 
> This fixes the following error:
> $ ethtool --set-rxfh-indir eth2 hfunc xor
> Cannot set RX flow hash configuration: Operation not supported

Ah, thanks for the fix!

In this case I wonder if we wouldn't be better off returning early 
in ethtool_check_flow_types() if input_xfrm is 0 or NO_CHANGE.
Most drivers will have get_rxfh_fields - still there's no point
in doing the check if they have empty ops->supported_input_xfrm

We could add a:

	if (WARN_ON(ops->supported_input_xfrm && !ops->get_rxfh_fields))
		return -EINVAL;

into ethtool_check_ops() and we'd be both safe and slightly faster.

WDYT?

Re: [PATCH net-next] ethtool: Fix set RXFH for drivers without RXFH fields support

[Gal Pressman]

On 10/07/2025 3:25, Jakub Kicinski wrote:
> On Wed, 9 Jul 2025 18:32:51 +0300 Gal Pressman wrote:
>> Some drivers (e.g., mlx4_en) support ->set_rxfh() functionality (such as
>> setting hash function), but not setting the RXFH fields.
>>
>> The requirement of ->get_rxfh_fields() in ethtool_set_rxfh() is there to
>> verify that we have no conflict with the RSS fields options, if it
>> doesn't exist then there is no point in doing the check.
>> Soften the check in ethtool_set_rxfh() so it doesn't fail when
>> ->get_rxfh_fields() doesn't exist.  
>>
>> This fixes the following error:
>> $ ethtool --set-rxfh-indir eth2 hfunc xor
>> Cannot set RX flow hash configuration: Operation not supported
> 
> Ah, thanks for the fix!
> 
> In this case I wonder if we wouldn't be better off returning early 
> in ethtool_check_flow_types() if input_xfrm is 0 or NO_CHANGE.
> Most drivers will have get_rxfh_fields - still there's no point
> in doing the check if they have empty ops->supported_input_xfrm

Makes sense.

> 
> We could add a:
> 
> 	if (WARN_ON(ops->supported_input_xfrm && !ops->get_rxfh_fields))
> 		return -EINVAL;
> 
> into ethtool_check_ops() and we'd be both safe and slightly faster.

This is a step further.

There could be a driver that allows setting of input xfrm but not rxfh
fields. Failing the netdevice registration is different than skipping
ethtool_check_flow_types().

Maybe there are no such devices and we shouldn't care?

Re: [PATCH net-next] ethtool: Fix set RXFH for drivers without RXFH fields support

[Jakub Kicinski]

On Thu, 10 Jul 2025 14:17:11 +0300 Gal Pressman wrote:
> > We could add a:
> > 
> > 	if (WARN_ON(ops->supported_input_xfrm && !ops->get_rxfh_fields))
> > 		return -EINVAL;
> > 
> > into ethtool_check_ops() and we'd be both safe and slightly faster.  
> 
> This is a step further.
> 
> There could be a driver that allows setting of input xfrm but not rxfh
> fields. Failing the netdevice registration is different than skipping
> ethtool_check_flow_types().
> 
> Maybe there are no such devices and we shouldn't care?

Note that we're talking about the get. It's still perfectly fine for
the hypothetical driver to not support _changing_ the fields, the fields
be hardwired. But we need to know what fields the device is using to
validate the xfrm is correct.