Hi Edward, On 13/11/2024 14:13, [email protected] wrote: > From: Edward Cree <[email protected]> > > 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 <[email protected]> > --- > 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 = {}; > >
