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: <20220429171717.5b0b2a81@kernel.org> Date: Fri, 29 Apr 2022 17:17:17 -0700 From: Jakub Kicinski <kuba@...nel.org> To: "Nambiar, Amritha" <amritha.nambiar@...el.com> Cc: "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>, "davem@...emloft.net" <davem@...emloft.net>, "pabeni@...hat.com" <pabeni@...hat.com>, "edumazet@...gle.com" <edumazet@...gle.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Mogilappagari, Sudheer" <sudheer.mogilappagari@...el.com>, "Samudrala, Sridhar" <sridhar.samudrala@...el.com>, "Sreenivas, Bharathi" <bharathi.sreenivas@...el.com>, Jamal Hadi Salim <jhs@...atatu.com> Subject: Re: [PATCH net-next 01/11] ice: Add support for classid based queue selection On Fri, 29 Apr 2022 23:43:06 +0000 Nambiar, Amritha wrote: > > > HW. > > > Example: > > > $ tc filter add dev ens4f0 protocol ip ingress flower\ > > > dst_ip 192.168.1.12 ip_proto tcp dst_port 5001\ > > > skip_sw classid ffff:0x5 > > > > > > The above command adds an ingress filter, the accepted packets > > > will be directed to queue 4. The major number represents the ingress > > > > ..and "directed" here. TC is used for so many different things you > > really need to explain what your use case is. > > > > Sorry about using the terms "forward" and "direct" interchangeably in this > context. I should have been more consistent with the terminology. > > The use case is to accept incoming packets into a queue via TC ingress filter. > TC filters are offloaded to a hardware table called the "switch" table. This > table supports two types of actions in hardware termed as "forward to queue" and > "forward to a VSI aka queue-group". Accepting packets into a queue using > ethtool filter is also supported, but this type of filter is added into a > different hardware table called the "flow director" table. The flow director > table has certain restrictions that it can only have filters with the same packet > type. The switch table does not have this restriction. > > > > qdisc. The general rule is "classID's minor number - 1" upto max > > > queues supported. The queue number is in hex format. > > > > The "general rule" you speak of is a rule you'd like to establish, > > or an existing rule? > > This is an existing rule already being used in the TX qdiscs. We are using > this in the ingress qdisc and offloading RX filters following the explanation > from Netdev 0x13 session presented by Jamal. Section 4.1 from > https://legacy.netdevconf.info/0x13/session.html?talk-tc-u-classifier > "There is one interesting tidbit on the above rule exposed > via the "classid 1:1" construct: the accepted packets will be > queued to DMA ring 0. If classid 1:2 was used then they > would be queued to DMA ring 1 etc. The general rule is the > "classid's minor number - 1" upto a max of DMA queues > supported by the NIC (64 in the case of the ixgbe). By definition, this is > how tc classids are intended to be used i.e they select queues (in this > case hardware ingress queues)." So we're faking mqprio behavior on ingress? I guess that's fine. Wouldn't SKBEDIT_F_QUEUE_MAPPING be a more natural fit here?
Powered by blists - more mailing lists