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

[shaharf]

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. Having
an application other then the SM respond to the sminfo would not work in
the current scheme.  As a matter of fact it maybe catastrophic - meaning
it may lead to multiple masters SM in the subnet!!! 

 

I really don't understand what resources you refer to. I think I know
the OpenSM pretty well but maybe I have new things to learn. Please
enlighten me.

Ref-counting too is useless. There should be only one SM on the port. I
see not reason to change that.

 

Shahar

 

________________________________

From: Eitan Zahavi [mailto:eitan at mellanox.co.il] 
Sent: Monday, January 10, 2005 6:43 PM
To: shaharf; Eitan Zahavi; Michael S. Tsirkin; Roland Dreier
Cc: openib-general at openib.org
Subject: RE: [openib-general] Some Missing Features from mthca/user MAD
access

 

Shahar> Yes, but when you want to respond to attributes you have to
specify a mask. Using that mask you can register to any attribute set
you want.

Yes, but if the application (that is not an SM) will use a mask that has
the sminfo set - it will be considered an SM.

I would prefer having the SMBit stay on when the SM dies then having
spurious SMBit transitions.

It will take more resources from the SM when these bits will start to
change.

Also you will need to start ref-counting on the port since several apps
can share it and they will not obey the rule for not masking the sminfo
if they are not SMs.

 

Eitan Zahavi

Design Technology Director

Mellanox Technologies LTD

Tel:+972-4-9097208
Fax:+972-4-9593245

P.O. Box 586 Yokneam 20692 ISRAEL

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050110/25495266/attachment.html>