Re: [RFC] rdma/uverbs: Sketch for an ioctl framework

Jason Gunthorpe
2016-05-25T22:13:40Z

On Wed, May 25, 2016 at 09:46:16PM +0000, Hefty, Sean wrote:
> > #6 seems 'not like the others' - seems like a reasonable concrete
> > thing to consider as we build the objects on the
> > framework. [understanding that compat operation is still required]
>
> I agree. Handling event reporting in general is slightly different
> from the other objections. But it ties in with object close
> processing, so I think the framework needs something here.

Yes, some kind of core framework seem essential here, and funneling
all events seems reasonable if we can figure out how.

> #6 is based on examining the application APIs and driving
> requirements down. I.e. poll a single fd to get all events: CQ
> notifications, async events, CM disconnect events, etc. And while
> I'm thinking about it, expand events to support user specified.
> This would allow many apps to rid themselves of socketpairs which
> currently fill that role.

socketpairs? I always use eventfds for that kind of stuff..

Are you hearing people object to number of fds? I've never thought of
it as such a big deal, epoll makes it very painless to deal with.. Do
people have scaling issues?

What would be nice is having strong synchronization in the event
stream, eg between cm (dis)connection and related cq events so those
unexpected races go away...

Jason