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.
