[openib-general] RE: userspace event reporting

Libor Michalek libor at topspin.com
Wed Jul 20 17:01:59 PDT 2005


On Tue, Jul 12, 2005 at 10:20:33PM -0700, Fab Tillier wrote:
> > From: Michael S. Tsirkin [mailto:mst at mellanox.co.il]
> > Quoting r. Sean Hefty <sean.hefty at intel.com>:
> > >
> > > I believe that this is purely a userspace issue.  I can't see why
> > > using a mutex wouldn't work, but I believe that get_event() currently
> > > blocks waiting for an event.
> > >
> > > Note that get_event() may be reporting events associated with an
> > > object other than the one being destroyed.
> > 
> > Maybe, create a special kind of event after the object has been destroyed?
> 
> So I think anyway I look at it, the uCM ends up needing to shadow the
> CM IDs in user-land to maintain references.  If it does that, then Sean's
> earlier idea of performing reference counting and blocking destruction
> should work fine and maintain the synchronous behavior that exists today.

  Correct, this is the way it was done in the gen1 userspace CM. There
is a table, protected by a lock, that keeps a reference counted level
of indirection between the kernel cm_id and the user visible id.

  My question is do we really want this, since an application will likely
have yet another table containing the app specific connection structure.
How that table is locked and managed will differ based on the threading
model. I think it's an incorrect assumption that if we create this level
thread safety in the uCM then the app connection structure can be placed
in a uCM user supplied pointer (e.g. the kCM context variable) and avoid
this type of app level connection table.


-Libor



More information about the general mailing list