Re: Query on new ethtool RSS hashing options

[Vladimir Oltean <olteanv@gmail.com>]

On Sat, Mar 06, 2021 at 06:04:14PM +0530, Sunil Kovvuri wrote:
> On Sat, Mar 6, 2021 at 5:47 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > On Fri, Mar 05, 2021 at 03:07:02PM -0800, Jakub Kicinski wrote:
> > > On Fri, 5 Mar 2021 16:15:51 +0530 Sunil Kovvuri wrote:
> > > > Hi,
> > > >
> > > > We have a requirement where in we want RSS hashing to be done on packet fields
> > > > which are not currently supported by the ethtool.
> > > >
> > > > Current options:
> > > > ehtool -n <dev> rx-flow-hash
> > > > tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 m|v|t|s|d|f|n|r
> > > >
> > > > Specifically our requirement is to calculate hash with DSA tag (which
> > > > is inserted by switch) plus the TCP/UDP 4-tuple as input.
> > >
> > > Can you share the format of the DSA tag? Is there a driver for it
> > > upstream? Do we need to represent it in union ethtool_flow_union?
> >
> > Sorry, i missed the original question, there was no hint in the
> > subject line that DSA was involved.
> >
> > Why do you want to include DSA tag in the hash? What normally happens
> > with DSA tag drivers is we detect the frame has been received from a
> > switch, and modify where the core flow dissect code looks in the frame
> > to skip over the DSA header and parse the IP header etc as normal.
>
> I understand your point.
> The requirement to add DSA tag into RSS hashing is coming from one of
> our customer.
>
> >
> > Take a look at net/core/flow_dissect.c:__skb_flow_dissect()
> >
> > This fits with the core ideas of the network stack and offloads. Hide
> > the fact an offload is being used, it should just look like a normal
> > interface.
> >
> >         Andrew
>
> Yes, the pkt will look like a normal packet itself.
> In our case HW strips the DSA tag from the packet and forwards it to a VF.

DSA-aware SR-IOV on master, very interesting. I expect that the reverse
is true as well: on xmit, the VF will automatically insert a FWD tag
into the packet too, which encodes a 'virtual' source port and switch id.

What Marvell controller is this? How is the SR-IOV implemented in the
kernel, is it modeled as switchdev, with host representors for the VFs?
Does it support VEPA mode or VEB too? If it supports VEB, does it learn
(more like 'steal') addresses from the DSA switch's FDB? Does it also
push addresses into the DSA switch's FDB?

To your question: why stop at hashing? What about flow steering?
What does your hardware actually support? It is obvious that it has deep
parsing of Marvell DSA tags specifically, so the generic 'masked u32 key'
matching may not be the best way to model this. Can your DSA master even
perform masked matching on generic u32 keys, or are you planning to just
look for the particular pattern of a Marvell DSA tag in the ethtool
rxnfc callbacks, and reject anything that doesn't match?