On Mon, May 16, 2011 at 2:13 PM, Hefty, Sean <sean.he...@intel.com> wrote:
> libibverbs
> ----------
> We define a new device capability flag IBV_DEVICE_EXT_OPS, indicating that
> the library supports extended operations. If set, the provider library
> returns an extended structure from ibv_open_device():
>
> struct ibv_context_ext {
> struct ibv_context context;
> int version;
> struct ibv_ext_ops ext_ops;
> };
>
> The ext_ops will allow for additional operations not provided by
> ibv_context_ops, for example:
>
> struct ibv_ext_ops {
> int (share_pd)(struct ibv_pd *pd, int fd, int oflags);
> };
>
> In order for libibverbs to check for ext_ops support, it steals a byte from
> the device name:
>
> /*
> * Support for extended operations is recorded at the end of
> * the name character array.
> */
> #define ext_ops_cap name[IBV_SYSFS_NAME_MAX - 1]
I like this idea of allowing for future extensibility... but if we
could go even a bit further
and have support for named extensions, I think that would be even better. ie
we could define a bunch of new XRC related stuff and then have some interface
to the driver where we ask for the "XRC" extension (by name with a string) then
that would be very handy for the future.
I wonder if a "ummunotify" extension would make integrating ummunotify
stuff into
libibiverbs easier...
This is inspired by my very limited knowledge of OpenGL, so maybe a
more detailed
look at the mechanism there would be helpful.
I think stealing a byte from the name to mark this support might make sense, but
then I would probably go a bit further and change the second parameter of
ibv_register_driver to be an ibv_driver_init_func_ext() so we can extend even
before the open of the driver.
Anyway thanks for rebooting this work, Sean.
- R.
--
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
