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
| ||
|
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
Powered by blists - more mailing lists