[PATCH] net/mlx5: deprecate representor matching devarg

[PATCH] net/mlx5: deprecate representor matching devarg

[Dariusz Sosnowski]

Mark repr_matching_en device argument exposed by mlx5 PMD
as deprecated and schedule its removal in 25.11 release.

Functionality exposed by this device argument does not fit
current E-Switch representor model exposed by DPDK.
A new unified representor model, described in
https://fast.dpdk.org/events/slides/DPDK-2024-07-unified_representor.pdf
should be developed.

Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
---
 doc/guides/nics/mlx5.rst             |  4 ++++
 doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
 2 files changed, 15 insertions(+)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index c3a350d24e..7311a9849b 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1636,6 +1636,10 @@ for an additional list of options shared with other mlx5 drivers.
     item added. Flow rules based on this pattern template will match
     the vport associated with port on which rule is created.
 
+  .. note::
+
+      This parameter is deprecated and will be removed in future releases.
+
 - ``max_dump_files_num`` parameter [int]
 
   The maximum number of files per PMD entity that may be created for debug information.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e2d4125308..bbc35516b0 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -152,3 +152,14 @@ Deprecation Notices
 * bus/vmbus: Starting DPDK 25.11, all the vmbus API defined in
   ``drivers/bus/vmbus/rte_bus_vmbus.h`` will become internal to DPDK.
   Those API functions are used internally by DPDK core and netvsc PMD.
+
+* net/mlx5: ``repr_matching_en`` device argument is deprecated
+  and will be removed in DPDK 25.11 release.
+  With disabled representor matching, behavior of Rx datapath in mlx5 PMD
+  is incompatible with current DPDK representor model.
+  Packets from any E-Switch port can arrive on any representor,
+  depending only on created flow rules.
+  Such working model should be exposed directly in DPDK ethdev API,
+  without relying on flow API.
+  Currently there is no alternative API providing the same functionality as
+  with ``repr_matching_en`` set to 0.
-- 
2.39.5

Re: [PATCH] net/mlx5: deprecate representor matching devarg

[Thomas Monjalon]

16/07/2025 11:38, Dariusz Sosnowski:
> Mark repr_matching_en device argument exposed by mlx5 PMD
> as deprecated and schedule its removal in 25.11 release.
> 
> Functionality exposed by this device argument does not fit
> current E-Switch representor model exposed by DPDK.
> A new unified representor model, described in
> https://fast.dpdk.org/events/slides/DPDK-2024-07-unified_representor.pdf
> should be developed.
> 
> Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>

The impact is very limited.
There is no API/ABI breakage.
The devarg is probably not used a lot.
To be on a completely safe side, the devarg could continue to be accepted
if a user set it at its default value.
Still, announcing this is a good idea in case someone uses this.

Applied, thanks.

Re: [PATCH] net/mlx5: deprecate representor matching devarg

[Adrian Schollmeyer]

Hi,

On 16.07.25 11:38, Dariusz Sosnowski wrote:

> Mark repr_matching_en device argument exposed by mlx5 PMD
> as deprecated and schedule its removal in 25.11 release.
>
> [...]
>
> A new unified representor model, described in
> https://fast.dpdk.org/events/slides/DPDK-2024-07-unified_representor.pdf
> should be developed.

The unified representor model seems to only address aggregation of 
traffic of all ports to a single representor (the e-switch manager port).
In our use case with BlueField DPUs, however, traffic is always 
intercepted by the DPU and handled differently depending on whether the 
traffic came from one of the host representors (i.e. the host system or 
a VM) or one of the physical port representors (i.e. the the network 
fabric).
These two traffic groups are usually processed by disjoint sets of CPUs 
processing disjoint sets of DPDK ports.
With repr_matching_en=0, we can flexibly steer traffic from many 
represented ports to different representors (e.g. dummy SF representors) 
to aggregate traffic by port group on the receive path.
To do this, we create flow rules that tag packets received from the 
represented ports accordingly and match traffic by this tag in ingress 
flow rules for the aggregation representors. This is only possible with 
repr_matching_en=0, since only then traffic coming from arbitrary ports 
can be matched.

Hence my question: Can such a flexible mapping still be achieved without 
repr_matching_en=0? Otherwise, removal of this devarg would break our 
use case.

Best regards
Adrian

-- 

Adrian Schollmeyer

SysEleven GmbH
Boxhagener Straße 80
10245 Berlin

T +49 30 / 23 32 012-0
F +49 30 / 61 67 55 5-0

https:// www.syseleven.de <https://www.syseleven.de>
https://www.linkedin.com/company/ syseleven-gmbh 
<https://www.linkedin.com/company/syseleven-gmbh>

Current system status always at:
https://www.syseleven-status.net/

Company headquarters: Berlin
Registered court: AG Berlin Charlottenburg, HRB 108571 Berlin
Managing directors: Andreas Hermann, Jens Ihlenfeld, Jens Plogsties, 
Andreas Rückriegel

       

Re: [PATCH] net/mlx5: deprecate representor matching devarg

[Thomas Monjalon]

23/07/2025 11:07, Adrian Schollmeyer:
> Hi,
> 
> On 16.07.25 11:38, Dariusz Sosnowski wrote:
> 
> > Mark repr_matching_en device argument exposed by mlx5 PMD
> > as deprecated and schedule its removal in 25.11 release.
> >
> > [...]
> >
> > A new unified representor model, described in
> > https://fast.dpdk.org/events/slides/DPDK-2024-07-unified_representor.pdf
> > should be developed.
> 
> The unified representor model seems to only address aggregation of 
> traffic of all ports to a single representor (the e-switch manager port).
> In our use case with BlueField DPUs, however, traffic is always 
> intercepted by the DPU and handled differently depending on whether the 
> traffic came from one of the host representors (i.e. the host system or 
> a VM) or one of the physical port representors (i.e. the the network 
> fabric).
> These two traffic groups are usually processed by disjoint sets of CPUs 
> processing disjoint sets of DPDK ports.
> With repr_matching_en=0, we can flexibly steer traffic from many 
> represented ports to different representors (e.g. dummy SF representors) 
> to aggregate traffic by port group on the receive path.
> To do this, we create flow rules that tag packets received from the 
> represented ports accordingly and match traffic by this tag in ingress 
> flow rules for the aggregation representors. This is only possible with 
> repr_matching_en=0, since only then traffic coming from arbitrary ports 
> can be matched.

Thanks a lot for your detailed feedback.

> Hence my question: Can such a flexible mapping still be achieved without 
> repr_matching_en=0? Otherwise, removal of this devarg would break our 
> use case.

I invite you to participate in discussions in the follow-up patches to come.
I understand we must find a solution to cover your use case.
I hope it can be part of an ethdev API, instead of mlx5 specific behavior.