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

[Slava Ovsiienko <viacheslavo@nvidia.com>]

Hi, David

> -----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.

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.
> 
> > 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