All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Edward Srouji <edwards@nvidia.com>
Cc: Saeed Mahameed <saeedm@nvidia.com>,
	Tariq Toukan <tariqt@nvidia.com>, Mark Bloch <mbloch@nvidia.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Yishai Hadas <yishaih@mellanox.com>,
	linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Mark Bloch <markb@mellanox.com>,
	Michael Gur <michaelgur@nvidia.com>,
	Patrisious Haddad <phaddad@nvidia.com>
Subject: Re: [PATCH rdma-next 0/5] RDMA/mlx5: Add NIC_RX_CLASS steering domain for RDMA classification
Date: Sun, 15 Nov 2026 16:06:24 +0200	[thread overview]
Message-ID: <20261115140624.GF42525@unreal> (raw)
In-Reply-To: <20261103-rdma-rx-classifier-v1-0-1ad6c8cfe936@nvidia.com>

On Tue, Nov 03, 2026 at 08:12:48PM +0200, Edward Srouji wrote:
> mlx5 devices recognise RDMA traffic on receive with a fixed classifier: UDP
> destination port 4791. Packets that match are handed to the RDMA receive path
> (NIC_RX_RDMA); everything else continues down the normal NIC RX path.
> 
> RDMA transports that identify their packet differently don't reach the
> RDMA receive path as they use a different packet format entirely.
> 
> This series adds NIC_RX_CLASS, a new per-vport receive steering domain placed
> ahead of NIC_RX/NIC_RX_RDMA. It gives a privileged RDMA transport manager a
> programmable classification stage that supports matching on arbitrary header
> fields and marking the packet as RDMA.
> 
> NIC_RX_CLASS reuses the model used by RDMA_TRANSPORT_RX/TX domains:
> - one root namespace per vport, owned by the eswitch manager;
> - targeted from userspace by `ib_port`, as with the existing per-vport
>   domains;
> - gated by `rdma_transport_manager`, and by
>   `rdma_transport_manager_other_eswitch` for the cross-eswitch (LAG /
>   socket-direct) case;
> - restricted to callers holding the same UCAP that per-port matchers already
>   require, so an unprivileged process cannot program another vport's
>   classification.
> 
> A rule in this domain takes no destination: it matches, attaches a
> modify-header action to mark the packet as RDMA and explicitly allows it
> onward. ALLOW is the only terminal action the domain accepts; a flow counter
> may be attached alongside it.
> 
> Patch 1 adds the IFC bits, patch 2 fixes ALLOW handling in the FTE merge
> logic, patch 3 unifies the per-vport root namespace init/cleanup helpers,
> and patch 4 adds the NIC_RX_CLASS domain itself. Patch 5 exposes the new
> domain and the ALLOW action to userspace.
> 
> Patches 1-4 are mlx5_core changes and are targeted at the shared mlx5-next
> branch, prefixed accordingly; patch 5 depends on them and is targeted at
> rdma-next.
> 
> Signed-off-by: Edward Srouji <edwards@nvidia.com>
> ---
> Michael Gur (5):
>       net/mlx5: Add NIC_RX_CLASS IFC bits
>       net/mlx5: fs, treat ALLOW as a conflicting action upon merge
>       net/mlx5: fs, refactor RDMA transport manager root namespace init/cleanup
>       net/mlx5: fs, add NIC_RX_CLASS steering domain support
>       RDMA/mlx5: Expose NIC_RX_CLASS flow table type to userspace

I applied this to mlx5-next and rdma-next.

Thanks

      parent reply	other threads:[~2026-11-15 14:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 18:12 [PATCH rdma-next 0/5] RDMA/mlx5: Add NIC_RX_CLASS steering domain for RDMA classification Edward Srouji
2026-11-03 18:12 ` [PATCH mlx5-next 1/5] net/mlx5: Add NIC_RX_CLASS IFC bits Edward Srouji
2026-11-03 18:12 ` [PATCH mlx5-next 2/5] net/mlx5: fs, treat ALLOW as a conflicting action upon merge Edward Srouji
2026-11-03 18:12 ` [PATCH mlx5-next 3/5] net/mlx5: fs, refactor RDMA transport manager root namespace init/cleanup Edward Srouji
2026-11-03 18:12 ` [PATCH mlx5-next 4/5] net/mlx5: fs, add NIC_RX_CLASS steering domain support Edward Srouji
2026-11-03 18:12 ` [PATCH rdma-next 5/5] RDMA/mlx5: Expose NIC_RX_CLASS flow table type to userspace Edward Srouji
2026-11-11 13:38   ` Michael Gur
2026-11-15 14:06 ` Leon Romanovsky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261115140624.GF42525@unreal \
    --to=leon@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=edwards@nvidia.com \
    --cc=jgg@ziepe.ca \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=markb@mellanox.com \
    --cc=mbloch@nvidia.com \
    --cc=michaelgur@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=phaddad@nvidia.com \
    --cc=saeedm@nvidia.com \
    --cc=tariqt@nvidia.com \
    --cc=yishaih@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.