[openib-general] Some Missing Features from mthca/user MAD access

[Michael S. Tsirkin]

Hello!
Quoting r. Roland Dreier (roland.list at gmail.com) "Re: [openib-general] Some Missing Features from mthca/user MAD access":
> > Yes, I think it is. It involves catching CTRL-C in the application
> > and other such horror, and it never works 100%.
> > And what about running to opensms on the same HCA?
> > I think it is clearly kernel's job to handle synchronisation and do cleanups
> > when application exits.
> 
> OK, we can have a file for controlling capability bits.
> 
> > After consideration, I think the proper way is add a reference count
> > and clean is_sm when it falls to 0.
> > This way runnning two opensms on the same HCA and two different
> > HCAs in the same subnet behaves the same.
> 
> I don't understand this.  IsSM is per-port, so what does it mean for the
> reference count of IsSM for a port to be 2?  Two SMs are running on that
> port?

I am trying to say it could be transparent. you could be running
two sms and it could work more or less.
So for example opensm hangs. If I kill it, it will clear the 
is_sm bit, *but* I dont want that.
The way to do it cold be to start a new one, then kill
the old one.

If userspace wants exclusivity there are standard interfaces for
this like flock , we should nto enforce policty I think.


> > To do this, I think either and ioctl on umad, or
> > a flag to open to set this bit is not too bad though.
> 
> I don't like either the ioctl() or a magic flag for open().  I'm
> trying to decide
> between a special issm file, or changing the umad file interface to put a
> command code in the structure that is passed via write() (this would also
> let us add a mechanism for canceling MADs).
> 
>  - R.

issm file lets you get the current issm status and so find out
if someone is running sm, in a clean way.
So I am for it. "everything is a file".

MST