Re: [net-next] net: sched: extend flow action with RSS

[Hariprasad Kelam]

> -----Original Message-----
> From: Dave Taht <dave.taht@xxxxxxxxx>
> ----------------------------------------------------------------------
> On Sat, Oct 21, 2023 at 10:53 PM Sunil Kovvuri <sunil.kovvuri@xxxxxxxxx>
> wrote:
> >
> > On Sat, Oct 21, 2023 at 1:43 AM Nambiar, Amritha
> > <amritha.nambiar@xxxxxxxxx> wrote:
> > >
> > > >> On Fri, Oct 20, 2023 at 2:12 AM Hariprasad Kelam
> > > >> <hkelam@xxxxxxxxxxx>
> > > >> wrote:
> > > >>>
> > > >>> This patch extends current flow action with RSS, such that the
> > > >>> user can install flower offloads with action RSS followed by a group
> id.
> > > >>> Since this is done in hardware skip_sw flag is enforced.
> > > >>
> > > >> Our typical rule for TC is we need s/w equivalence for offloads.
> > > >> How would this work in absence of offload?
> > > >>
> > > > [Hari]
> > > > Our typical rule for TC is we need s/w equivalence for offloads. How
> would this work in absence of offload?
> > > >
> > > > This patch we added as an extension to receive queue selection in
> hardware.
> > > > This patch "act_skbedit: skbedit queue mapping for receive queue"
> > > > enabled receive queue selection in hardware and skip_sw is enforced.
> > > >
> > > > Adding stakeholders of this patch, to get their opinion.
> > > > sridhar.samudrala@xxxxxxxxx  amritha.nambiar@xxxxxxxxx
> > > >
> > > > incase of RSS, hardware makes decisions about incoming packets
> before they are even received in the queue.
> 
> Is there any way to do a LPM to queue match on inbound?
> 
AFAIK, LPM (longest prefix match) is used to make routing decisions by comparing the destination ip address bit-by-bit with prefixes in the routing table.
Where on a typice UDP/TCP packet, RSS considers Source IP/Destination IP and Sport and Dport these fields to make decision on the queue mapping.



> > > >
> > >
> > > The skip_sw for skbedit receive queue action was enforced as the
> > > only other alternative was a new hw-only action, or changing the
> > > action mirred. See discussion at
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org
> > > _netdev_20220921132929.3f4ca04d-
> 40kernel.org_&d=DwIFaQ&c=nKjWec2b6R0
> > > mOyPaz7xtfQ&r=2bd4kP44ECYFgf-
> KoNSJWqEipEtpxXnNBKy0vyoJJ8A&m=_GDltrUw
> > > pNUkk5hvYOtlzFeW-rAeZy4_1bSWUdGVen-
> sJDjMWkmLw7pVfDH7OHBX&s=SGwkF4_m8
> > > 5hkScL8rNnbVPvDwEnNalysi6x6ual5NHY&e=
> > >
> > > Few questions WRT this patch:
> > > How are the rss groups created? ethtool rss contexts? Any reason to
> > > use TC to direct to rss contexts over using ethtool context ids?
> > >
> >
> > Yes, RSS groups are created using ethtool.
> > Ethtool ntuple is very limited in expressing flow rules and since the
> > general direction is to use 'TC', we are attempting to add RSS action
> > to 'TC'.
> >
> >
> > > IIUC, skbedit is meant to only edit skb metadata such as mark,
> > > packet type, queue mapping, priority etc. Even if this is a HW only
> > > action and has no use in the stack, would skbedit be the right fit here?
> > >
> >
> > The thought was to keep related actions like RQ, RSS group etc under
> > one action ie skbedit.
> > If that's not the right place we can add a separate action.
> >
> > Thanks,
> > Sunil.
> >
> 
> 
> --
> Oct 30: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__netdevconf.info_0x17_news_the-2Dmaestro-2Dand-2Dthe-2Dmusic-
> 2Dbof.html&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=2bd4kP44ECYFgf-
> KoNSJWqEipEtpxXnNBKy0vyoJJ8A&m=_GDltrUwpNUkk5hvYOtlzFeW-
> rAeZy4_1bSWUdGVen-
> sJDjMWkmLw7pVfDH7OHBX&s=gKGp2Lqrx7O6ZAfoWGSQeb__T6PYk8SzKHSf
> SxtoNLU&e=
> Dave Täht CSO, LibreQos