DPDK patches and discussions
 help / color / mirror / Atom feed
From: Raslan Darawsheh <rasland@nvidia.com>
To: Bing Zhao <bingz@nvidia.com>,
	Slava Ovsiienko <viacheslavo@nvidia.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Ori Kam <orika@nvidia.com>,
	Dariusz Sosnowski <dsosnowski@nvidia.com>,
	Suanming Mou <suanmingm@nvidia.com>,
	Matan Azrad <matan@nvidia.com>
Subject: Re: [PATCH] net/mlx5: fix the uplink port probing in bond mode
Date: Sun, 21 Jul 2024 12:11:29 +0000	[thread overview]
Message-ID: <MN0PR12MB6056FE70DF215307135E1DF0CFAF2@MN0PR12MB6056.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20240717163541.324772-1-bingz@nvidia.com>

Hi,

From: Bing Zhao <bingz@nvidia.com>
Sent: Wednesday, July 17, 2024 7:35 PM
To: Slava Ovsiienko; dev@dpdk.org; Raslan Darawsheh
Cc: Ori Kam; Dariusz Sosnowski; Suanming Mou; Matan Azrad
Subject: [PATCH] net/mlx5: fix the uplink port probing in bond mode

In the HW-LAG bonding mode, the representor port can be from both
slave PFs. When probing a representor (REP), the UPLINK (proxy) port
always needs to be probed firstly before any REP port.

In the current implementation, when probing a device with the
following format:

  -a 0000:XX:00.0,dv_flow_en=N,representor=pf1vfy

Since the REP belongs to the 2nd PF in the bonding, the UPLINK would
not be added into the probing ports list.

1. In dv_flow_en=1 mode, the REP itself can be probed. But it didn't
   obey the rules and the behaviors were inconsistent.
    a. When probing the REP from 1st PFs, the UPLINK was also probed.
    b. When detaching the UPLINK, all REPs were detached.
2. In dv_flow_en=2 mode, since some resources can only be allocated /
   created on the proxy port, the probing would get a failure.

By removing the unneeded check of the bonding PF device index, the
UPLINK will always try to be probed with any format.

Fixes: 2e569a370395 ("net/mlx5: add VF LAG mode bonding device recognition")

Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh


      reply	other threads:[~2024-07-21 12:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-17 16:35 Bing Zhao
2024-07-21 12:11 ` 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=MN0PR12MB6056FE70DF215307135E1DF0CFAF2@MN0PR12MB6056.namprd12.prod.outlook.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=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;
as well as URLs for NNTP newsgroup(s).