Re: [PATCH ethtool-next] rxclass: Make output for RSS context action explicit

[Joe Damato <jdamato@fastly.com>]

On Fri, Nov 08, 2024 at 07:56:41PM +0000, Edward Cree wrote:
> On 08/11/2024 19:32, Daniel Xu wrote:
> > Currently, if the action for an ntuple rule is to redirect to an RSS
> > context, the RSS context is printed as an attribute. At the same time,
> > a wrong action is printed. For example:
> > 
> >     # ethtool -X eth0 hfunc toeplitz context new start 24 equal 8
> >     New RSS context is 1
> > 
> >     # ethtool -N eth0 flow-type ip6 dst-ip $IP6 context 1
> >     Added rule with ID 0
> > 
> >     # ethtool -n eth0 rule 0
> >     Filter: 0
> >             Rule Type: Raw IPv6
> >             Src IP addr: :: mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
> >             Dest IP addr: <redacted> mask: ::
> >             Traffic Class: 0x0 mask: 0xff
> >             Protocol: 0 mask: 0xff
> >             L4 bytes: 0x0 mask: 0xffffffff
> >             RSS Context ID: 1
> >             Action: Direct to queue 0
> > 
> > This is wrong and misleading. Fix by treating RSS context as a explicit
> > action. The new output looks like this:
> > 
> >     # ./ethtool -n eth0 rule 0
> >     Filter: 0
> >             Rule Type: Raw IPv6
> >             Src IP addr: :: mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
> >             Dest IP addr: <redacted> mask: ::
> >             Traffic Class: 0x0 mask: 0xff
> >             Protocol: 0 mask: 0xff
> >             L4 bytes: 0x0 mask: 0xffffffff
> >             Action: Direct to RSS context id 1
> > 
> > Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> 
> I believe this patch is incorrect.  My understanding is that on
>  packet reception, the integer returned from the RSS indirection
>  table is *added* to the queue number from the ntuple rule, so
>  that for instance the same indirection table can be used for one
>  rule distributing packets over queues 0-3 and for another rule
>  distributing a different subset of packets over queues 4-7.
> I'm not sure if this behaviour is documented anywhere, and
>  different NICs may have different interpretations, but this is
>  how sfc ef10 behaves.

I just wanted to chime in and say that my understanding has always
been more aligned with Daniel's and I had also found the ethtool
output confusing when directing flows that match a rule to a custom
context.

If Daniel's patch is wrong (I don't know enough to say if it is or
not), would it be possible to have some alternate ethtool output
that's less confusing? Or for this specific output to be outlined in
the documentation somewhere?