RE: [RFC] XRC upstream merge reboot

Hefty, Sean
2011-05-18T17:30:30Z

> 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