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

[shaharf]

Michael,
	What you are proposing is a new mechanism. It may be good or
not. Yes you can invent new mechanisms to use the is_sm bit. Right now
there is none except the sminfo handshake. Even if you invent new
mechanisms to use the IS_SM bit, it does not change the following fact:
if you set the IS_SM bit you should reply to sminfo. This is out of our
control. This is how the discovery is defined in the IB spec. Letting
other applications to set the IS_SM but without responding to SMINFO is
annoying in the best case and very dangerous in the other cases. In most
cases it would mean that the SM (any SM) will not be able to work
because it will fail to register to SMINFO.
And NO, the kernel can not respond to the sminfo requests because it
doesn't know its state. Again failing to report the correct state may
end with multiple MASTER SMS on the subnet.

Shahar

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst at mellanox.co.il]
> Sent: Monday, January 10, 2005 7:05 PM
> To: shaharf
> Cc: Eitan Zahavi; Roland Dreier; openib-general at openib.org
> Subject: Re: [openib-general] Some Missing Features from mthca/user
MAD
> access
> 
> Hello!
> Quoting r. shaharf (shaharf at voltaire.com) "RE: [openib-general] Some
> Missing Features from mthca/user MAD access":
> > Eitan, the main (and only) purpose of the IS_SM bit is for SM to SM
> > coordination. As a matter of fact it means that when discavering a
port
> with
> > this bit you have to query it with sminfo to see if he is the master
or
> maybe
> > it should be the master. There is not other use.
> 
> BTW I thought maybe sending a query to the SM LID from another node
> and use the is sm bit to check whether opensm is running on the subnet
> is a useful trick.
> 
> Because I think kernel + hardware will answer that even if user-space
> opensm is slow of blocked on something.
> 
> Right? So that will be a slightly different use of the IS_SM bit.
> 
> MST