[openib-general] [PATCH] osm: handle local events

[Michael S. Tsirkin]

Quoting r. Sasha Khapyorsky <sashak at voltaire.com>:
> Subject: Re: [openib-general] [PATCH] osm: handle local events
> 
> On 16:28 Thu 24 Aug     , Michael S. Tsirkin wrote:
> > Quoting r. Yevgeny Kliteynik <kliteyn at mellanox.co.il>:
> > > Index: libvendor/osm_vendor_ibumad.c
> > > ===================================================================
> > > --- libvendor/osm_vendor_ibumad.c	(revision 8998)
> > > +++ libvendor/osm_vendor_ibumad.c	(working copy)
> > > @@ -72,6 +72,7 @@
> > >  #include <opensm/osm_log.h>
> > >  #include <opensm/osm_mad_pool.h>
> > >  #include <vendor/osm_vendor_api.h>
> > > +#include <infiniband/verbs.h>
> > >  
> > >  /****s* OpenSM: Vendor AL/osm_umad_bind_info_t
> > >   * NAME
> > 
> > NAK.
> > 
> > This means that the SM becomes dependent on the uverbs module.  I don't think
> > this is a good idea.  Let's not go there - SM should depend just on the umad
> > module and libc.
> 
> Agree on this point. I dislike this new libibverbs dependency too. I
> think we need to work with umad.
> 
> So more generic question: some application performs blocked read() from
> /dev/umadN, should this read() be interrupted and return error (with
> appropriate errno value), then the port state becomes DOWN?
> I think yes, it should. Other opinions? Sean?

One thing seems obvious: if device goes away it seems obvious that we should
return ENODEV from any read. Isn't this already done?

> 
> And if yes, then in OpenSM we will need just to check errno value upon
> umad_recv() failure.
> 
> Sasha

Might be a good idea. Hoever, such an approach by default is an ABI change so it
could break some apps.  Could this be made an option somehow?  Think also about
a race where I read *after* the state was changed to DOWN.

Another question comes to mind:
does not SM care about physical link state changes as well?
Assuming I disconnect and re-connect the cable, does not
SM want to know and try bringing the logical link up?
How is this handled currently? Can the same mechanism be used
for port state events?

-- 
MST