Hi Eitan, On Thu, 2005-12-01 at 10:35, Eitan Zahavi wrote: > Hi Yael, > > As I read through the MgtWg mails I get the impression that an out of > spec mechanism is required to know if the other SM is trusted.
Yes, that was what I was proposing (in http://openib.org/pipermail/openib-general/2005-December/014186.html where I wrote "The SM needs a way to know whether the other SM(s) (and which ones) are trusted or not so the SM_Key can be filled in."): that OpenSM have a list of trusted SMs and OpenSM would use that information. > In that case and since OpenSM does not currently provide any such > mechanism, I would prefer never to send out the SM_Key on the request > and always send zero. Sending our SM_Key to a non - trusted SM is not a > good idea in my mind. > > OpenSM behavior should be to always trust any other SM. Above you said no other SM was trusted so do you mean not trust rather than trust other SMs ? > So any discovered SM that deserves to be the master should be granted > that right. Only if it were trusted and had the correct SM Key. -- Hal > Eitan Zahavi > Design Technology Director > Mellanox Technologies LTD > Tel:+972-4-9097208 > Fax:+972-4-9593245 > P.O. Box 586 Yokneam 20692 ISRAEL > > > > -----Original Message----- > > From: Yael Kalka > > Sent: Thursday, December 01, 2005 2:17 PM > > To: 'Hal Rosenstock'; Eitan Zahavi > > Cc: [email protected] > > Subject: RE: [Fwd: [openib-general] OpenSM and Wrong SM_Key] > > > > Hi Hal, Eitan, > > I think the best option is to add an OpenSM option flag - > exit_on_fatal. > > This flag can decide on the action on fatal cases: > > 1. Exit or not when seeing SM with different SM_Key. > > 2. Exit or not when there is a fatal link error (e.g - multiple > guids). > > etc. > > > > I tried to run 2 SMs just now with different SM_keys, and I see that > none of them > > exit, since both receive SM_Key=0 on SMInfo GetResp. > > The reason for that is that in the SMInfo Get request (as in all other > requests) > > we do not send anything in the mad data. Meaning - all fields are > clear. > > In the __osm_sminfo_rcv_process_get_request function we are checking > the state > > according > > to the payload data. This is always zero! Thus - SM will never know > that the SMInfo > > request is sent from an SM that is master. > > > > I will work on a fix for that. > > Yael > > > > -----Original Message----- > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 30, 2005 11:57 PM > > To: Yael Kalka; Eitan Zahavi > > Cc: [email protected] > > Subject: [Fwd: [openib-general] OpenSM and Wrong SM_Key] > > > > > > Hi Yael & Eitan, > > > > Based on the recent MgtWG discussions, are you still holding your > > position in terms of exiting OpenSM when a non matching SM Key is > > discovered ? Just wondering if I can issue a patch for this and clear > > this issue so OpenSM can be compliant for this aspect. Thanks. > > > > -- Hal > > > > -----Forwarded Message----- > > > > From: Hal Rosenstock <[EMAIL PROTECTED]> > > To: [email protected] > > Subject: [openib-general] OpenSM and Wrong SM_Key > > Date: 08 Nov 2005 16:08:47 -0500 > > > > Hi, > > > > Currently, when OpenSM receives SMInfo with a different SM_Key, it > exits > > as follows: > > > > > > void > > __osm_sminfo_rcv_process_get_response( > > IN const osm_sminfo_rcv_t* const p_rcv, > > IN const osm_madw_t* const p_madw ) > > { > > ... > > > > > > > > /* > > Check that the sm_key of the found SM is the same as ours, > > or is zero. If not - OpenSM cannot continue with configuration!. > */ > > if ( p_smi->sm_key != 0 && > > p_smi->sm_key != p_rcv->p_subn->opt.sm_key ) > > { > > osm_log( p_rcv->p_log, OSM_LOG_ERROR, > > "__osm_sminfo_rcv_process_get_response: ERR 2F18: " > > "Got SM with sm_key that doesn't match our " > > "local key. Exiting\n" ); > > osm_log( p_rcv->p_log, OSM_LOG_SYS, > > "Found remote SM with non-matching sm_key. Exiting\n" ); > > osm_exit_flag = TRUE; > > goto Exit; > > } > > > > C14-61.2.1 states that: > > A master SM which finds a higher priority master SM with the wrong > > SM_Key should not relinquish the subnet. > > > > Exiting OpenSM relinquishes the subnet. > > > > So it appears to me that perhaps this behavior of exiting OpenSM > should > > be at least contingent on the SM state and relative priority of the > > SMInfo received. Make sense ? If so, I will work on a patch for this. > > > > -- Hal > > > > > > _______________________________________________ > > openib-general mailing list > > [email protected] > > http://openib.org/mailman/listinfo/openib-general > > > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
