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. 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. So any discovered SM that deserves to be the master should be granted that right. 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
