> 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.
There is always a delay in the reporting of an event and the device list being updated, so I don't see a need to process all queued events.
In any case, the question is whether to report hot plug events and, if so, how.
> 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?
I would like the use of a single fd for all verbs/rdma cm events, rather than the multiplexing issue that exists today. If we decouple the fd from the device, apps have the freedom to continue with the same usage model as today or use fewer system resources.
As a use case, it may be worth looking at how the librdmacm can make use of device insertion/removal. It currently uses a statically built list of devices. I don't believe new devices can be used, while software resources for removed devices are never completely released.
- Sean
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
