On 3/6/2017 8:07 PM, Jason Gunthorpe wrote:
On Mon, Mar 06, 2017 at 04:06:43PM +0200, Yishai Hadas wrote:
From: Bodong Wang <bodong@xxxxxxxxxxxx>
This patch drops the need to extend the verbs layer each time with
some non generic fields when creating a CQ. It adds an option to set
some opaque vendor data in some generic way which can fit any vendor.
The solution introduced for creating a CQ but expects to fit for
other IB objects as of QP, SRQ, etc.
It comes as a pre-patch for supplying some private mlx5 fields in
downstream patches.
The solution:
1) Introduce a new comp_mask bit (i.e. IBV_CQ_INIT_ATTR_MASK_VENDOR_DATA)
and a matching void* vendor data field.
2) Vendor should expose its header file for direct access with
relevant private structures.
3) Application should supply the input based on vendor-defined structure.
4) Upon getting the private data the vendor will cast to its internal
structure and use the data as part of CQ creation.
I'm not sure I like this, why not create a mlx5dv_create_cq?
Below notes justify the suggested scheme comparing adding
mlx5dv_create_cq() API for that purpose:
1) From developer point of view it's fully preferred to use single API
(e.g. ibv_create_cq_ex) otherwise developer should choose, do I use
ibv_create_cq_ex() or mlx5dv_create_cq(). If I use the latter, do I need
mlx5dv_destroy_cq() or can I use ibv_destroy_cq()...
2) We would like to support this scheme for other calls as well and
enjoy libibverbs generic services on top, that's can be achieved by the
suggested scheme.
3) Other vendors can use the suggested scheme without the need to expose
any xxx_create_cq() API, all that is needed is just to expose direct H
file, this can be done also by mlx5 customers who don't want to use the
mlx5_dv direct calls but to enjoy from the option to supply vendor data
as part of CQ creation.
--
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
