[Intel-wired-lan] [BUG] ethtool_get_rxfh_indir will always fail with EINVAL for ice driver devices

[Intel-wired-lan] [BUG] ethtool_get_rxfh_indir will always fail with EINVAL for ice driver devices

[Cody Haas]

Hey there!

I believe I may have encountered a bug with the ice driver. I'm currently
evaluating a few e810 NICs using the ice in-tree driver for kernel
6.16.5-200.fc42.x86_64, and noticed I am unable to get the indirection table
using ethtool_get_rxfh_indir via ioctl. Doing some tracing it looks like
ethtool_get_rxfh_indir calls ice_get_rxfh, which then calls ice_get_rss_key.
In this call sequence the seed passed into ice_get_rss_key will always be null
as ethtool_get_rxfh_indir does not set the key in struct ethtool_rxfh_param
*rxfh and ice_get_rxfh passes the value through to ice_get_rss_key as
*seed without checking if it is null. Then ice_get_rss_key(..) will return
EINVAL when *seed is null.

I compared this to the behavior of the i40e driver, which is the driver we
currently use on our devices. It looks like this can happen on the i40e driver,
however since i40e_get_rxfh has the lookup table (lut) that it creates
locally it will be able to retrieve the indirection table via
ethtool_get_rxfh_indir.

Is this behavior in the ice driver intended? If no, I've got an idea on how to
go about fixing this. Do you have any documentation for creating a patch
for the ice driver? Also I've never done a kernel bisect before, and the
machine that's running the ice driver is quite slow at compiling the kernel.
If anyone knows when this might have been introduced that would be very
helpful.

We're currently evaluating these cards on a timeframe so any help would be
greatly appreciated.

Thanks!

Cody Haas

Re: [Intel-wired-lan] [BUG] ethtool_get_rxfh_indir will always fail with EINVAL for ice driver devices

[Przemek Kitszel]

On 10/30/25 19:40, Cody Haas wrote:
> Hey there!
> 

hi, thanks for the report and sorry for delay with answering!

> I believe I may have encountered a bug with the ice driver. I'm currently
> evaluating a few e810 NICs using the ice in-tree driver for kernel
> 6.16.5-200.fc42.x86_64, and noticed I am unable to get the indirection table
> using ethtool_get_rxfh_indir via ioctl. Doing some tracing it looks like
> ethtool_get_rxfh_indir calls ice_get_rxfh, which then calls ice_get_rss_key.
> In this call sequence the seed passed into ice_get_rss_key will always be null
> as ethtool_get_rxfh_indir does not set the key in struct ethtool_rxfh_param
> *rxfh and ice_get_rxfh passes the value through to ice_get_rss_key as
> *seed without checking if it is null. Then ice_get_rss_key(..) will return
> EINVAL when *seed is null.
> 
> I compared this to the behavior of the i40e driver, which is the driver we
> currently use on our devices. It looks like this can happen on the i40e driver,
> however since i40e_get_rxfh has the lookup table (lut) that it creates
> locally it will be able to retrieve the indirection table via
> ethtool_get_rxfh_indir.
> 
> Is this behavior in the ice driver intended? If no, I've got an idea on how to
> go about fixing this. Do you have any documentation for creating a patch
> for the ice driver? Also I've never done a kernel bisect before, and the
> machine that's running the ice driver is quite slow at compiling the kernel.
> If anyone knows when this might have been introduced that would be very
> helpful.
> 

This behavior is not intended, and a fix would be much welcomed.
Here are bits specific to the networking (vs general kernel) patch
submission:
https://docs.kernel.org/process/maintainer-netdev.html#using-device-managed-and-cleanup-h-constructs
For Intel Ethernet, please use IWL-net or IWL-next as a tag, and CC IWL
(as you did here)

Regarding bisection, there were a few rxfh-related changes by Ahmed
Zaki, you could check at those points instead of full bisection

> We're currently evaluating these cards on a timeframe so any help would be
> greatly appreciated.
> 
> Thanks!
> 
> Cody Haas