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

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

Message-ID: <20220923060200.5effc63e@kernel.org>
Date:   Fri, 23 Sep 2022 06:02:00 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Nambiar, Amritha" <amritha.nambiar@...el.com>
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

On Fri, 23 Sep 2022 01:09:38 +0000 Nambiar, Amritha wrote:
> > 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). 

Alright, I guess that could work as well, thanks for the explanation.
Initially I thought that it'd be strange if the queue-set selection
was before aRFS and queue-id selection after, if they are both to be
controlled by TC. But I can see how that makes most practical sense :S