Re: New providers in rdma-core

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Wed, Oct 19, 2016 at 12:51:02PM -0700, Adit Ranadive wrote:

> I see that rxe still has a rxe-abi header in the providers/rxe folder.
> Would that also move to the kernel as part of the conversion?

Ideally, but it is blocked by this:

> One of the things I'm unclear about what happends to the IBV structs
> included in the user-level ABI headers, for example, the ibv_get_context_resp
> here:
> https://github.com/linux-rdma/rdma-core/blob/master/providers/mlx4/mlx4-abi.h#L48

This is the main thing preventing the use of the uapi headers - they
are actually *different* :(

It would be great if you have have some ideas on how to deal with
that.. This hasn't been tackled yet.

One choice is to write this:

struct mlx4_alloc_ucontext_resp_v3 {
	struct ibv_get_context_resp	ibv_resp;
	__u32				qp_tab_size;
	__u16				bf_reg_size;
	__u16				bf_regs_per_page;
};

as:

struct user_mlx4_alloc_ucontext_resp_v3 {
	struct ibv_get_context_resp	ibv_resp;
	struct mlx4_alloc_ucontext_resp_v3 udata;
};

Perhaps aided by a macro so we get high uniformity:

#define DECLARE_DRIVER_UDATA(struct_driver, struct_common)
  struct user # struct_driver {
     struct struct_common ibv_resp;
     struct struct_driver udata;
  };

Where mlx4_alloc_ucontext_resp_v3 comes from the uapi header, and is
not inlined, so each driver gets an 'abi wrapper' header that just
builds all these structs.

I'd probably advocate for that for new drivers if nothing more clever
comes forward. At least it is a step closer..

Another approach might be a different way to marshal the kernel call..

Jason
--
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