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

[Dave Taht]

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?

> > >
> >
> > 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://lore.kernel.org/netdev/20220921132929.3f4ca04d@xxxxxxxxxx/
> >
> > 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://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos