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

[Przemek Kitszel <przemyslaw.kitszel@intel.com>]

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