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  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]
Date:   Fri, 29 Apr 2022 17:17:17 -0700
From:   Jakub Kicinski <>
To:     "Nambiar, Amritha" <>
Cc:     "Nguyen, Anthony L" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "Mogilappagari, Sudheer" <>,
        "Samudrala, Sridhar" <>,
        "Sreenivas, Bharathi" <>,
        Jamal Hadi Salim <>
Subject: Re: [PATCH net-next 01/11] ice: Add support for classid based queue

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 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
> "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