DPDK patches and discussions
 help / color / mirror / Atom feed
From: Adrian Schollmeyer <a.schollmeyer@syseleven.de>
To: Dariusz Sosnowski <dsosnowski@nvidia.com>, dev@dpdk.org
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Michael Rossberg <michael.rossberg@tu-ilmenau.de>,
	Michael Pfeiffer <m.pfeiffer@syseleven.de>
Subject: Re: [PATCH] net/mlx5: deprecate representor matching devarg
Date: Wed, 23 Jul 2025 11:07:20 +0200	[thread overview]
Message-ID: <871879d3-b34c-4cea-9ae0-4715fb1c45fe@syseleven.de> (raw)
In-Reply-To: <20250716093846.1117794-1-dsosnowski@nvidia.com>

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

       


  parent reply	other threads:[~2025-07-23  9:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-16  9:38 Dariusz Sosnowski
2025-07-21 19:56 ` Thomas Monjalon
2025-07-23  9:07 ` Adrian Schollmeyer [this message]
2025-07-23  9:30   ` Thomas Monjalon

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=871879d3-b34c-4cea-9ae0-4715fb1c45fe@syseleven.de \
    --to=a.schollmeyer@syseleven.de \
    --cc=dev@dpdk.org \
    --cc=dsosnowski@nvidia.com \
    --cc=m.pfeiffer@syseleven.de \
    --cc=michael.rossberg@tu-ilmenau.de \
    --cc=thomas@monjalon.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).