Re: [dpdk-dev] [PATCH v2] common/mlx5: add provider query port support to glue library

Hi, David

-----Original Message-----
From: David Marchand <redacted>
Sent: Wednesday, June 23, 2021 16:52
To: Slava Ovsiienko <redacted>
Cc: dev <redacted>; Raslan Darawsheh <redacted>; Matan
Azrad [off-list ref]; NBU-Contact-Thomas Monjalon
[off-list ref]; dpdk stable [off-list ref]
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 [off-list ref]
wrote:

quoted

quoted

quoted

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.

I have no strong objections against "fix". The patch definitely can be
categorized as "fix" as well. It would be easier to push the patch to LTS 😊
I just tried to be extremely honest - upstream rdma-core did not provide this API,
now it does, it would be very nice to engage it, allowing full E-Switch support over
upstream rdma-core in some configurations. From other side - you are right,
w/o patch E-Switch might not work in DPDK, with patch - it should work.
Looks like a true magic fix 😊.

Yet "add provider quer port support to glue library" is just black magic to
most of us.

quoted

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.

This rdma-core API mostly reports E-Switch vport assigned indices, the assigning schema
of these ones depends on many factors - kernel/firmware/LAG configs/etc. Formerly,
the vport indices were assigned in direct correspondence with VF index, for these cases
E-Switch is supported fine even w/o API. But the newer kernel drivers with new features supported
changed the vport identification schema and former approach might not work, that's why this
API was introduced.

So, if I understand your comment correctly, we should tell few words the E-Switch
behavior might be affected and the feature malfunction is possible.

With best regards,
Slava