netdev - Re: Query on new ethtool RSS hashing options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+sq2Cdx4X7HBjdE8bU6OcS6g+yzx1Xj7n1VmPh_a+AoGPyvsg@mail.gmail.com>
Date:   Mon, 8 Mar 2021 18:55:54 +0530
From:   Sunil Kovvuri <sunil.kovvuri@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>,
        Linux Netdev List <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        George Cherian <gcherian@...vell.com>,
        Subbaraya Sundeep <sbhatta@...vell.com>,
        Sunil Goutham <sgoutham@...vell.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Alex Marginean <alexandru.marginean@....com>
Subject: Re: Query on new ethtool RSS hashing options

On Sat, Mar 6, 2021 at 6:48 PM Vladimir Oltean <olteanv@...il.com> wrote:
>
> 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@...n.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.

Yes, HW inserts the tag on the transmit side automatically.

>
> 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?

This is Marvell OcteonTx2/CN10K RVU controller
drivers/net/ethernet/marvell/octeontx2.
And no the controller doesn't have a internal switch and hence
currently there is no switchdev support.
The switch I referred to is an external one whose CPU port is
connected to this controller.

> 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?

The parser in the HW is configurable and can parse any header with a mask.

Thanks,
Sunil.