rdma-core new/old compatability

rdma-core new/old compatability

[Michal Kalderon]

Hi Kamal, Jason, 

Running a version of ibv_devinfo compiled against an old rdma-core (ibv_devinfo from libibverbs-utils-16.2-3-fc28.x86_64 )
failed to run with rdma-core release 28.0 for qedr.

The patch that caused this is commit c2841076
https://github.com/linux-rdma/rdma-core/commit/c28410765bdfe5cbed3cb2cdb1584eac3941469c#diff-8da8bc8b2790169de557d5dee83a278e
c28410765bdf 

libibverbs: Fix incorrect return code ...

The proper return code is EOPNOTSUPP when an operation is not supported.

Signed-off-by: Kamal Heib <kamalheib1@gmail.com>

The reason it failed is because qedr doesn't have a query_device_ex callback, so vctx->query_device_ex returns EOPNOTSUPP, and old libibverbs
Compares the return code to ENOSYS

I think applications compiled against old rdma-core should continue to run on new ones as well.
Can this commit be reverted? 

Thanks,
Michal

Re: rdma-core new/old compatability

[Jason Gunthorpe]

On Thu, Feb 27, 2020 at 01:11:13PM +0000, Michal Kalderon wrote:
> Hi Kamal, Jason, 
> 
> Running a version of ibv_devinfo compiled against an old rdma-core (ibv_devinfo from libibverbs-utils-16.2-3-fc28.x86_64 )
> failed to run with rdma-core release 28.0 for qedr.
> 
> The patch that caused this is commit c2841076
> https://github.com/linux-rdma/rdma-core/commit/c28410765bdfe5cbed3cb2cdb1584eac3941469c#diff-8da8bc8b2790169de557d5dee83a278e
> c28410765bdf 
> 
> libibverbs: Fix incorrect return code ...
> 
> The proper return code is EOPNOTSUPP when an operation is not supported.
> 
> Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
> 
> The reason it failed is because qedr doesn't have a query_device_ex
> callback, so vctx->query_device_ex returns EOPNOTSUPP, and old
> libibverbs Compares the return code to ENOSYS

This is surprising and unfortunate

> I think applications compiled against old rdma-core should continue
> to run on new ones as well.  Can this commit be reverted?

I would prefer to only revert the little bit that might be needed for
compatability.

Perhaps we should change the dummy function to implement
query_device_ex for all providers? Zeroing the extended data should be
sufficient I think.

Unfortunately we are changing return codes inadvertantly quite often,
and the providers tend to use different codes.

Jason

RE: [EXT] Re: rdma-core new/old compatability

[Michal Kalderon]

> From: Jason Gunthorpe <jgg@mellanox.com>
> Sent: Thursday, February 27, 2020 3:55 PM
> 
> ----------------------------------------------------------------------
> On Thu, Feb 27, 2020 at 01:11:13PM +0000, Michal Kalderon wrote:
> > Hi Kamal, Jason,
> >
> > Running a version of ibv_devinfo compiled against an old rdma-core
> > (ibv_devinfo from libibverbs-utils-16.2-3-fc28.x86_64 ) failed to run with
> rdma-core release 28.0 for qedr.
> >
> > The patch that caused this is commit c2841076
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_linux-
> > 2Drdma_rdma-
> 2Dcore_commit_c28410765bdfe5cbed3cb2cdb1584eac3941469c-23d
> > iff-
> 2D8da8bc8b2790169de557d5dee83a278e&d=DwIBAg&c=nKjWec2b6R0mOyP
> az7xt
> > fQ&r=5_8rRZTDuAS-6X-cGRU9Fo4yjCnkS1t7T3-
> gjL4FQng&m=8roKblaWiyWNhzEkhi8
> > gJYJs1ZHqJ0lqf_0OMh3fHBM&s=x5-
> fhg21NUEcxJ2zxM135ujpopHtey138zz9waiflS8
> > &e=
> > c28410765bdf
> >
> > libibverbs: Fix incorrect return code ...
> >
> > The proper return code is EOPNOTSUPP when an operation is not
> supported.
> >
> > Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
> >
> > The reason it failed is because qedr doesn't have a query_device_ex
> > callback, so vctx->query_device_ex returns EOPNOTSUPP, and old
> > libibverbs Compares the return code to ENOSYS
> 
> This is surprising and unfortunate
> 
> > I think applications compiled against old rdma-core should continue to
> > run on new ones as well.  Can this commit be reverted?
> 
> I would prefer to only revert the little bit that might be needed for
> compatability.
> 
> Perhaps we should change the dummy function to implement
> query_device_ex for all providers? Zeroing the extended data should be
> sufficient I think.
I've submitted pull-request #713 that implements the dummy function.

Thanks,
Michal

> 
> Unfortunately we are changing return codes inadvertantly quite often, and
> the providers tend to use different codes.
> 
> Jason