Re: [RFC] libibverbs IB device hotplug support

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2844 bytes --]

On 3/1/2017 1:00 PM, Hefty, Sean 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.

It can be done without a thread, that's not to say I would necessarily
do so myself.

> I didn't follow his idea for how the device list would be updated and
> kept in sync between the app and the library.

There is no requirement that the device list be kept in sync between the
library and the app, period.

There are three usages for what I suggested:

1)  The app gets a device list initially just like it does now.  If the
app never updates that list again, so be it.  This is 100% backward
compatible.

2)  The simplified version of hotplug/unplug that has been discussed:
the app calls ibv_get_device_list.  As proposed by Alex, the library
would rescan the sysfs directory on this call.  If the device is there,
great.  If it isn't, great too.  Under my proposed implementation, the
exact same thing is true.  If the device is there, great.  If there
isn't a new device in the list already, then great too.  Because the
initial implementation proposal left if up to the app to determine
how/when to check for a new device, there was never any guarantee that
whatever triggered the app to look for the new device meant that it was
ready to be used in sysfs and would be found by the re-reading of the
sysfs directory.  So whatever race might be present in my proposed
implementation would also be present in the original implementation.

3)  My proposed implementation where an entry point is added for async
events.  In this case, the library would not pass the event on up until
the device was ready to be used, so there is no race here.  And there is
minimal delay from detection to notification and ready for use.

> 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.

No, I wouldn't try that at all.  The inherently racy thing in all of
this is having the library be responsible for scanning a device, but not
responsible for detecting that there is a new device to be scanned.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]