From: Slava Ovsiienko <viacheslavo@nvidia.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>, Raslan Darawsheh <rasland@nvidia.com>,
Matan Azrad <matan@nvidia.com>,
NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
dpdk stable <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] common/mlx5: add provider query port support to glue library
Date: Thu, 24 Jun 2021 10:10:08 +0000 [thread overview]
Message-ID: <DM6PR12MB3753A122B7ECFCAF9D52AC96DF079@DM6PR12MB3753.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CAJFAV8yYp1W0WAWawHVnpwP3trvgfCcbazoKZzLD3L+g4yLhcg@mail.gmail.com>
Hi, David
Thank you for the review and comments.
What do you think about the commit message like this?
common/mlx5: fix rdma-core v35 query port API support
The rdma-core mlx5 provider introduced the port attributes query
API since version v35.0 - the mlx5dv_query_port routine. In order
to support this change in the rdma-core the conditional compilation
flag HAVE_MLX5DV_DR_DEVX_PORT_V35 is introduced by the this patch.
In the OFED rdma-core version the new compatible mlx5dv_query_port
routine was introduced as well, replacing the existing proprietary
mlx5dv_query_devx_port routine. The proprietary routine was
controlled in PMD code with HAVE_MLX5DV_DR_DEVX_PORT conditional
flag.
Currently, the OFED rdma-core library contains both versions of
port query API. And this version is a transitional one, there are
the plans to remove the proprietary mlx5dv_query_devx_port routine
and the HAVE_MLX5DV_DR_DEVX_PORT flag in PMD will not work anymore.
We had one more dependency on this flag in the code (for the
mlx5dv_dr_action_create_dest_ib_port routine) and the patch
fixes mentioned dependency also, by introducing the new
dedicated conditional flag - HAVE_MLX5DV_DR_CREATE_DEST_IB_PORT.
The introduced port query API is related to getting kernel
metadata indices assigned to the vports of E-switch. Without
engaging the API the PMD makes the assumptions about the indices,
those might be incorrect for some configurations (for example -
LAG ones) and the E-switch feature might not operate correctly.
This patch is highly desirable to be provided in DPDK LTS releases
due to it covers the major compatibility issue.
(I will add cc: and fixes tag while sending the update)
With best regards,
Slava
> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Wednesday, June 23, 2021 16:52
> To: Slava Ovsiienko <viacheslavo@nvidia.com>
> Cc: dev <dev@dpdk.org>; Raslan Darawsheh <rasland@nvidia.com>; Matan
> Azrad <matan@nvidia.com>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; dpdk stable <stable@dpdk.org>
> Subject: Re: [dpdk-dev] [PATCH v2] common/mlx5: add provider query port
> support to glue library
>
> On Wed, Jun 23, 2021 at 1:27 PM Slava Ovsiienko <viacheslavo@nvidia.com>
> wrote:
> > > > This patch is highly desirable to be provided in DPDK LTS releases
> > > > due to it covers the major compatibility issue.
> > >
> > > This patch is a fix, yet nothing tells this story in the title.
> >
> > This patch is not a fix. Actually it covers the compatibility issue, not a bug.
>
> I still think it counts as a fix in the sense that the mlx5 driver behavior
> changes to an undesired state if rdma-core gets updated.
>
> It's not about preferring "fix" in the title.
> It is more accurate/descriptive to me.
> If you feel strongly against "fix", I won't insist.
>
> Yet "add provider quer port support to glue library" is just black magic to
> most of us.
>
>
> > The Upstream rdma-core was evolved, its community adopted a slightly
> > different API version than was presented in the vendor version.
> > Our PMD should conform both versions and we provided this patch for
> DPDK.
>
> Let's try differently.
> Place yourself as someone who does not know a thing about the mlx5 driver
> and rdma-core.
> How does such a person understand the impact of this patch?
>
> I would state in the title that the mlx5 driver can now handle correctly rdma-
> core 35.
> Additionally, it could indicate which feature X is now behaving as intended.
> But if feature X is something internal to the mlx5 driver, it is worth skipping.
>
>
>
> --
> David Marchand
next prev parent reply other threads:[~2021-06-24 10:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-19 12:48 Viacheslav Ovsiienko
2021-06-20 8:25 ` Raslan Darawsheh
2021-06-23 10:42 ` David Marchand
2021-06-23 11:27 ` Slava Ovsiienko
2021-06-23 13:51 ` David Marchand
2021-06-23 15:39 ` Slava Ovsiienko
2021-06-24 10:10 ` Slava Ovsiienko [this message]
2021-07-01 7:15 ` [dpdk-dev] [PATCH v3 1/2] " Viacheslav Ovsiienko
2021-07-01 7:15 ` [dpdk-dev] [PATCH v3 2/2] common/mlx5: fix compilation flag on port query API Viacheslav Ovsiienko
2021-07-06 13:49 ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2021-07-06 13:44 ` [dpdk-dev] [PATCH v3 1/2] common/mlx5: add provider query port support to glue library Thomas Monjalon
2021-07-07 15:54 ` [dpdk-dev] [PATCH v4 " Viacheslav Ovsiienko
2021-07-07 15:54 ` [dpdk-dev] [PATCH v4 2/2] common/mlx5: fix compilation flag on port query API Viacheslav Ovsiienko
2021-07-07 17:39 ` Thomas Monjalon
2021-07-07 17:12 ` [dpdk-dev] [PATCH v4 1/2] common/mlx5: add provider query port support to glue library Thomas Monjalon
2021-07-08 16:07 ` Raslan Darawsheh
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=DM6PR12MB3753A122B7ECFCAF9D52AC96DF079@DM6PR12MB3753.namprd12.prod.outlook.com \
--to=viacheslavo@nvidia.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=matan@nvidia.com \
--cc=rasland@nvidia.com \
--cc=stable@dpdk.org \
--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).