Re: [PATCH rdma-core 4/5] verbs: Add an option to provide vendor private data when creating a CQ

[Yishai Hadas <yishaih-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html