netdev - RE: [net-next PATCH v2 0/4] 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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 23 Sep 2022 01:09:38 +0000
From:   "Nambiar, Amritha" <amritha.nambiar@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "alexander.duyck@...il.com" <alexander.duyck@...il.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 v2 0/4] Extend action skbedit to RX queue mapping

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Thursday, September 22, 2022 5:29 AM
> To: Nambiar, Amritha <amritha.nambiar@...el.com>
> Cc: netdev@...r.kernel.org; alexander.duyck@...il.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 v2 0/4] Extend action skbedit to RX queue
> mapping
> 
> On Thu, 22 Sep 2022 08:19:07 +0000 Nambiar, Amritha wrote:
> > > Alex pointed out that it'd be worth documenting the priorities of
> > > aRFS vs this thing, which one will be used if HW matches both.
> >
> > Sure, I will document the priorities of aRFS and TC filter selecting
> > the Rx queue. On Intel E810 devices, the TC filter selecting Rx queue
> > has higher priority over aRFS (Flow director filter) if both the filters
> > are matched.
> 
> Is it configurable? :S If we think about RSS context selection we'd
> expect the context to be selected based on for example the IPv6 daddr
> of the container but we still want aRFS to select the exact queue...

This behavior is similar on E810 currently, i.e., TC filter selects the set
of queues (like the RSS context), and then the flow director filter can
be used to select the exact queue within the queue-set. We want to have
the ability to select the exact queue within the queue-set via TC (and not
flow director filter).

On E810, TC filters are added to hardware block called the "switch". This
block supports two types of actions in hardware termed as "forward to
queue" and  "forward to queue-set". aRFS filters are added to a different
HW block called the "flow director" (FD). The FD block comes after the switch
block in the HW pipeline. The FD block has certain restrictions (can only
have filters with the same packet type). The switch table does not have
this restriction.

When both the TC filter and FD filter competes for queue selection (i.e. both
filters are matched and action is to set a queue), the pipeline resolves
conflicts based on metadata priority. The priorities are not user configurable.
The ICE driver programs these priorities based on metadata at each stage,
action etc. Switch (TC) filters with forward-to-queue action have higher 
priority over FD filter assigning a queue. The hash filter has lowest priority.

> Is there a counterargument for giving the flow director higher prio?

Isn't the HW behavior on RX (WRT to setting the queue) consistent
with what we have in SW for TX ? In SW, TX queue set via TC filter
(skbedit action) has the highest precedence over XPS and jhash (lowest).