DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Raslan Darawsheh <rasland@nvidia.com>
To: Dariusz Sosnowski <dsosnowski@nvidia.com>,
	Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
	Bing Zhao <bingz@nvidia.com>, Ori Kam <orika@nvidia.com>,
	Suanming Mou <suanmingm@nvidia.com>,
	Matan Azrad <matan@nvidia.com>
Cc: dev@dpdk.org, stable@dpdk.org
Subject: Re: [PATCH v2] net/mlx5: use port index as representor index
Date: Thu, 4 Jun 2026 12:36:55 +0300	[thread overview]
Message-ID: <d8c2a1d6-fa06-4a61-9ff6-a1574cddfd89@nvidia.com> (raw)
In-Reply-To: <20260525091733.558838-1-dsosnowski@nvidia.com>

Hi,


On 25/05/2026 12:17 PM, Dariusz Sosnowski wrote:
> Since the offending commit, mlx5 driver supports probing
> representors on BlueField DPUs with Socket Direct (SD).
> Such card can be connected to 2 different CPUs on the host system.
> On DPU, user would see the following network devices:
> 
> - p0 and p1 - physical ports
> - pf0hpf and pf2hpf - PF0 on CPU 0 and CPU 1 respectively
> - pf1hpf and pf3hpf - PF1 on CPU 0 and CPU 1 respectively
> 
> mlx5 driver finds the relevant netdev by matching information
> provided in representor devarg to phys_port_name
> reported by Linux kernel.
> For the above interfaces phys_port_name's would be reported
> and probed as:
> 
> - p0 -> p0, no need for representor devarg
> - p1 -> p1, with representor=pf1
> - pf0hpf -> c1pf0, with representor=c1pf0vf65535
> - pf1hpf -> c1pf1, with representor=c1pf1vf65535
> - pf2hpf -> c2pf0, with representor=c2pf0vf65535
> - pf3hpf -> c2pf1, with representor=c2pf1vf65535
> 
> Although hot-plugging all these representors is successful,
> RTE_ETH_FOREACH_MATCHING_DEV() macro would not find DPDK ports.
> This is caused missing information reported by mlx5 driver,
> through rte_eth_representor_info_get() API.
> Specifically, mlx5 driver did not report controller index for all
> representor ranges.
> 
> Until now mlx5 driver used static encoding for 16-bit representor_id:
> 
> - 2 bits for representor type
> - 2 bits for PF index
> - 12 bits for representor index (either VF or SF number)
> 
> Controller index was not encoded. This caused the mentioned issue
> and on top of that:
> 
> - limits the number of PFs
> - limits the number of SFs
> 
> This patch changes the mlx5 driver logic for
> rte_eth_representor_info_get().
> Instead of static encoding:
> 
> - representor_id's will be dynamically assigned
>    to each probed representor.
> - rte_eth_representor_info_get() will report N ranges:
>      - N == number of probed ports on single embedded switch
>      - Each range will define single representor_id
>        for given controller/PF/VF/SF.
> 
> Fixes: 2f7cdd821b1b ("net/mlx5: fix probing to allow BlueField Socket Direct")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
> Acked-by: Bing Zhao <bingz@nvidia.com>
> ---
> v2:
> - Added missing "not" in "RTE_ETH_FOREACH_MATCHING_DEV() macro would not find DPDK ports"
>    in the commit message.
> - Fixed typo in number of bits for representor index.
>    Should be 12, not 2.
> 
>   drivers/net/mlx5/linux/mlx5_os.c |   6 +-
>   drivers/net/mlx5/mlx5.h          |  19 +++
>   drivers/net/mlx5/mlx5_ethdev.c   | 284 +++++++++++++++++++------------
>   3 files changed, 199 insertions(+), 110 deletions(-)
> 
--

Patch applied to next-net-mlx,

Kindest regards
Raslan Darawsheh


      reply	other threads:[~2026-06-04  9:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-22 10:19 [PATCH] net/mlx5: use port index as representor index Dariusz Sosnowski
2026-05-25  9:17 ` [PATCH v2] " Dariusz Sosnowski
2026-06-04  9:36   ` Raslan Darawsheh [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=d8c2a1d6-fa06-4a61-9ff6-a1574cddfd89@nvidia.com \
    --to=rasland@nvidia.com \
    --cc=bingz@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=dsosnowski@nvidia.com \
    --cc=matan@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=stable@dpdk.org \
    --cc=suanmingm@nvidia.com \
    --cc=viacheslavo@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox