Re: [RFC] XRC upstream merge reboot

Roland Dreier
2011-05-18T16:44:01Z

On Mon, May 16, 2011 at 2:13 PM, Hefty, Sean <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 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.