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

Message-ID: <CAKgT0UcCrEAfiEi-EVkXAmZxdyD910yr2v54iYe3nzQdaX+6ng@mail.gmail.com>
Date:   Thu, 8 Sep 2022 08:27:42 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Amritha Nambiar <amritha.nambiar@...el.com>
Cc:     netdev@...r.kernel.org, kuba@...nel.org, jhs@...atatu.com,
        jiri@...nulli.us, xiyou.wangcong@...il.com,
        vinicius.gomes@...el.com, sridhar.samudrala@...el.com
Subject: Re: [net-next PATCH v2 0/4] Extend action skbedit to RX queue mapping

On Wed, Sep 7, 2022 at 6:14 PM Amritha Nambiar
<amritha.nambiar@...el.com> wrote:
>
> Based on the discussion on
> https://lore.kernel.org/netdev/20220429171717.5b0b2a81@kernel.org/,
> the following series extends skbedit tc action to RX queue mapping.
> Currently, skbedit action in tc allows overriding of transmit queue.
> Extending this ability of skedit action supports the selection of receive
> queue for incoming packets. Offloading this action is added for receive
> side. Enabled ice driver to offload this type of filter into the
> hardware for accepting packets to the device's receive queue.
>
> v2: Added documentation in Documentation/networking
>
> ---
>
> Amritha Nambiar (4):
>       act_skbedit: Add support for action skbedit RX queue mapping
>       act_skbedit: Offload skbedit queue mapping for receive queue
>       ice: Enable RX queue selection using skbedit action
>       Documentation: networking: TC queue based filtering

I don't think skbedit is the right thing to be updating for this. In
the case of Tx we were using it because at the time we stored the
sockets Tx queue in the skb, so it made sense to edit it there if we
wanted to tweak things before it got to the qdisc layer. However it
didn't have a direct impact on the hardware and only really affected
the software routing in the device, which eventually resulted in which
hardware queue and qdisc was selected.

The problem with editing the receive queue is that the hardware
offloaded case versus the software offloaded can have very different
behaviors. I wonder if this wouldn't be better served by being an
extension of the mirred ingress redirect action which is already used
for multiple hardware offloads as I recall.

In this case you would want to be redirecting packets received on a
port to being received on a specific queue on that port. By using the
redirect action it would take the packet out of the receive path and
reinsert it, being able to account for anything such as the RPS
configuration on the device so the behavior would be closer to what
the hardware offloaded behavior would be.