Hi Edward,
On 13/11/2024 14:13, edward.cree@xxxxxxx wrote:
> From: Edward Cree <ecree.xilinx@xxxxxxxxx>
>
> Ethtool ntuple filters with FLOW_RSS were originally defined as adding
> the base queue ID (ring_cookie) to the value from the indirection table,
> so that the same table could distribute over more than one set of queues
> when used by different filters.
TBH, I'm not sure I understand the difference? Perhaps you can share an
example?
> However, some drivers / hardware ignore the ring_cookie, and simply use
> the indirection table entries as queue IDs directly. Thus, for drivers
> which have not opted in by setting ethtool_ops.cap_rss_rxnfc_adds to
> declare that they support the original (addition) semantics, reject in
> ethtool_set_rxnfc any filter which combines FLOW_RSS and a nonzero ring.
> (For a ring_cookie of zero, both behaviours are equivalent.)
> Set the cap bit in sfc, as it is known to support this feature.
>
> Signed-off-by: Edward Cree <ecree.xilinx@xxxxxxxxx>
> ---
> diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
> index 7da94e26ced6..d86399bcf223 100644
> --- a/net/ethtool/ioctl.c
> +++ b/net/ethtool/ioctl.c
> @@ -992,6 +992,11 @@ static noinline_for_stack int ethtool_set_rxnfc(struct net_device *dev,
> if (rc)
> return rc;
>
> + /* Nonzero ring with RSS only makes sense if NIC adds them together */
> + if (info.flow_type & FLOW_RSS && !ops->cap_rss_rxnfc_adds &&
> + ethtool_get_flow_spec_ring(info.fs.ring_cookie))
> + return -EINVAL;
I believe this check shouldn't happen when we do ETHTOOL_SRXCLSRLDEL as
flow_type is garbage, WDYT?
> +
> if (ops->get_rxfh) {
> struct ethtool_rxfh_param rxfh = {};
>
>
