> As long as the version number in the ibv_context is increasing and not
> branching then I think it is OK. 0 = what we have now. 1 = + XRC, 2 =
> +XRC+ummunotify, etc. Drivers 0 out the function pointers they do not
> support.
I was thinking more along this line, but I can see how using a named extension
could be useful for OFED or vendor specific extensions that aren't part of the
upstream libibverbs. (Whether _that_ is useful is another matter, but it seems
to be the world that we're in anyway.)
I'm not familiar with OpenGL, so I'll take a look at it. (The concept sounds
similar to Window's COM interfaces.)
Beyond the interfaces, are there any thoughts on how to handle structure
changes, such as:
struct ibv_xrc_send_wr {
struct ibv_send_wr wr;
uint32_t remote_qpn;
};
? Do we want to use the existing ibv_post_send() call, or add a new
ibv_post_xrc_send() routine specifically for this purpose (and simplify the
above definition)?
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
