Hi, David > -----Original Message----- > From: David Marchand <david.march...@redhat.com> > Sent: Wednesday, June 23, 2021 16:52 > To: Slava Ovsiienko <viachesl...@nvidia.com> > Cc: dev <dev@dpdk.org>; Raslan Darawsheh <rasl...@nvidia.com>; Matan > Azrad <ma...@nvidia.com>; NBU-Contact-Thomas Monjalon > <tho...@monjalon.net>; dpdk stable <sta...@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 <viachesl...@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
