> > struct ibv_context {
> > struct ibv_device *device;
> > struct ibv_context_ops ops;
> > int cmd_fd;
> > int async_fd;
> > int num_comp_vectors;
> > pthread_mutex_t mutex;
> > void *abi_compat;
> > struct ibv_xrc_op *xrc_ops;
> > };
> >
>
> We don't need to have this as a pointer, really (I'd like to save the
> extra malloc and associated bookkeeping).
I think we could actually have libmlx4 have one copy of xrc_ops and
set the pointer to point at its copy. And then the tests in each of
the xrc operations become just 'if (!context->xrc_ops) return ENOSYS;"
But it's not a big deal really.
> If we have the ibv_xrc_op struct at the end of ibv_context, this is
> sufficient for backwards binary compatibility(libmlx4 itself
> allocates the ibv_context structure for libibverbs. If the actual
> structure is a bit bigger, who cares -- we just need to preserve
> the current offsets of the structure fields for binary
> compatibility).
Yes, that's true. I don't have much objection to adding a struct
ibv_xrc_ops inside the structure (rather than the pointer as I
suggested).
> If you want to be a bit more generic, we could do this as an "extra_ops"
> structure and add new ops as needed.
Actually I'd prefer to add xrc_ops and then if we need to extend
further with more new ops, add another structure afterw it. That way
we avoid having to put any define in libibverbs to tell drivers like
libmlx4 that xrc support is present; libmlx4 et al can just use
AC_CHECK_MEMBER(struct ibv_context.xrc_ops) to test with autoconf.
- R.
_______________________________________________
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
