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

[Thomas Monjalon <thomas@monjalon.net>]

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.