netdev - RE: [PATCH net-next 01/11] ice: Add support for classid based queue selection

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <MWHPR11MB1293C17C30E689270E0C39AAF1FC9@MWHPR11MB1293.namprd11.prod.outlook.com>
Date:   Fri, 29 Apr 2022 23:43:06 +0000
From:   "Nambiar, Amritha" <amritha.nambiar@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>
CC:     "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

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Thursday, April 28, 2022 4:04 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@...el.com>
> Cc: davem@...emloft.net; pabeni@...hat.com; edumazet@...gle.com;
> Nambiar, Amritha <amritha.nambiar@...el.com>; netdev@...r.kernel.org;
> Mogilappagari, Sudheer <sudheer.mogilappagari@...el.com>; Samudrala,
> Sridhar <sridhar.samudrala@...el.com>; Sreenivas, Bharathi
> <bharathi.sreenivas@...el.com>
> Subject: Re: [PATCH net-next 01/11] ice: Add support for classid based queue
> selection
> 
> On Thu, 28 Apr 2022 10:24:20 -0700 Tony Nguyen wrote:
> > This patch uses TC flower filter's classid feature to support
> > forwarding packets to a device queue. Such filters with action
> > forward to queue will be the highest priority switch filter in
> 
> You say "forward" here..
> 
> > 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)."