On Wed, Mar 1, 2017 at 8:00 PM, Hefty, Sean <sean.hefty@xxxxxxxxx> wrote: >> > > I don't think that we should introduce an asych context into >> libibverbs. >> > >> > Why not? >> >> Generally, I dislike the idea of running threads from libraries, >> particularly libraries like ibverbs. So many apps get no benefit from >> the thread, but it sits there connected to udev.. > > I thought Doug was referring to reporting the device add/remove event through some event reporting interface, like what the librdmacm already does. So no threads for that are needed. IMO, this makes sense. > > I didn't follow his idea for how the device list would be updated and kept in sync between the app and the library. > > If you had device add/remove events, the get_event call could intercept that event and update the device list there. But I don't know that you try to sync a shared list between the library and the app. In order to provide 'out-of-ibv_context' libibverbs events we'll need a new interface, something like ibv_get_system_event(), to report device changes. Every time the application calls this API, libibverbs must process all events in queue in order to have an up to date ibv_device list with they way it appears in sysfs. Then, do we force all these popped events on the user? or can we force him to loop on ibv_get_system_event() until EAGAIN so we're sure the device list is updated? Is this hiding yet another fd for the application to block on? Verbs is built around a cmd_fd per ibv_context. Reporting of new devices hotplug needs a separate channel. It does not seem correct to add yet another such cdev to verbs. I agree the adding this hotplug report capabilities into librdmacm sounds more appropriate. But libibvers will still need to provide the latest ibv_device list snapshot as it appears in sysfs. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
