On 3/8/2017 12:22 AM, Jason Gunthorpe wrote:
It is very common to have 'basic' and 'complex' API entry points. I
don't see a problem here.
It's not an issue of 'basic' and 'complex' API but a question of code
sharing and resource managing.
Using *one* API (i.e. ibv_create_cq_ex) shares the libibverbs code on
the creation path. Look at current code at '__lib_ibv_create_cq_ex()',
it manages locking, ref_counting and set the IB attributes, in the
future it may do other shared stuff as well.
Creating common IB objects as of CQ/QP/etc. with some vendor specific
API might end-up with code duplication, missing functionality or even
might lead to some bugs as of out-of-sync with the main path creation
of libibverbs.
Think about future feature of resource tracking per context as of
handling recovery/error flow on its objects upon getting a device fatal
event, collecting statistics on its open objects ,etc.
We expect a shared code for the above in few places in libibverbs. Being
part of the standard flow should guarantee that any future feature will
be added automatically without a special care from any vendor. As the
underlay object is really an IB standard object it makes sense to have a
single API for its creation.
Once the correct structure is used there should be *no* safety issue, please
note that the vendor data defined to be as some extended structure which can
only be grown based on comp_mask so that compatibility will be saved in any
case.
No, you still have to make sure that your ib_device is somehow a mlx5.
We are talking on an application that previously read some vendor
capabilities using a direct API (e.g. mlx5dv_query_device) to know
whether the vendor functionality is supported.
As same ibv_context is used in both APIs (e.g. mlx5dv_query_device,
ibv_create_cq_ex) it should be very clear to application's writer which
vendor is used.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
