netdev - RE: [net-next PATCH 0/3] Extend action skbedit to RX queue mapping

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 2 Sep 2022 08:37:13 +0000
From:   "Nambiar, Amritha" <amritha.nambiar@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "alexander.h.duyck@...el.com" <alexander.h.duyck@...el.com>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "jiri@...nulli.us" <jiri@...nulli.us>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "Gomes, Vinicius" <vinicius.gomes@...el.com>,
        "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Subject: RE: [net-next PATCH 0/3] Extend action skbedit to RX queue mapping

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Wednesday, August 31, 2022 7:46 PM
> To: Nambiar, Amritha <amritha.nambiar@...el.com>
> Cc: netdev@...r.kernel.org; alexander.h.duyck@...el.com;
> jhs@...atatu.com; jiri@...nulli.us; xiyou.wangcong@...il.com; Gomes,
> Vinicius <vinicius.gomes@...el.com>; Samudrala, Sridhar
> <sridhar.samudrala@...el.com>
> Subject: Re: [net-next PATCH 0/3] Extend action skbedit to RX queue mapping
> 
> On Tue, 30 Aug 2022 02:28:39 -0700 Amritha Nambiar wrote:
> > Based on the discussion on
> > https://lore.kernel.org/netdev/20220429171717.5b0b2a81@kernel.org/,
> > the following series extends skbedit tc action to RX queue mapping.
> > Currently, skbedit action in tc allows overriding of transmit queue.
> > Extending this ability of skedit action supports the selection of receive
> > queue for incoming packets. Offloading this action is added for receive
> > side. Enabled ice driver to offload this type of filter into the
> > hardware for accepting packets to the device's receive queue.
> 
> Thinking about this again - is redirecting to a queue really the most
> useful API to expose? Wouldn't users want to redirect to a set of
> queues, i.e. RSS context?
> 
> Or in your case the redirect to a set of queues is done by assigning
> a class?
> 
We already support redirecting to a set of queues using the 'hw_tc' option
of tc-flower. From the man page of tc-flower:
"hw_tc TCID - Specify a hardware traffic class to pass matching packets on to.
 TCID is in the range 0 through 15."
We needed two levels of filtering via TC, the first level selects the set of
queues, and an additional level that selects a queue within the queue-set 
(from the first level). Hence redirecting to a queue as an action. The additional
advantage is that being a tc-action allows using other action controls on this,
action chaining via "pipe" with other tc actions, and continuing classification
via action control "continue" etc.

> Either way we should start documenting things, so please find (/create)
> some place under Documentation/networking where we can make notes for
> posterity.

Agree. I'll update the man page for tc-skbedit action. I can add notes in
Documentation/networking as well.