Hi Sean, Well, this is a very old topic well discussed years ago. All credits to Ashok Raj which you know better then me. The argument against the idea for the SM to be the keeper of these registrations goes as follows:
Our problem has to do with data that is not persistently stored in the fabric (which is: Multicast MGID->MLID mapping, Service-Records and InformInfo records). Without the use of client re-registration the only way to keep this data consistent between the master SM and its standby slaves (or across SM restarts) is by using a transaction safe model. Transaction safe models are well known and require distributed handshake or journaling systems (in our case distributed ones). Anyway what this means is that every transaction (like creation of new Service Record or registering to a multicast group) will have to be first committed and approved by all standby SMs before it is responded. This strict transaction safe model is not fitting very well with the requirement for scalability of the fabric - which is hard to make even without that complication. The Client-Re-Registration concept resolves this need as the clients need to track their registrations and repeat them with the new master SM. Eitan Zahavi Senior Engineering Director, Software Architect Mellanox Technologies LTD Tel:+972-4-9097208 Fax:+972-4-9593245 P.O. Box 586 Yokneam 20692 ISRAEL > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:openib-general- > [EMAIL PROTECTED] On Behalf Of Sean Hefty > Sent: Wednesday, May 31, 2006 7:35 PM > To: Leonid Arsh > Cc: Roland Dreier; [email protected] > Subject: Re: [openib-general][PATCH 1 of 3] repost: Client Reregister support for > kernel space > > Leonid Arsh wrote: > > the most urgent and critical case is > > the SM failure/restart when the SM is not connected to the host directly. > > Why not patch the SM to handle this sort of case and rebuild its database > without every client in the fabric needing to send it MADs? Why can't the SM > save/restore the configuration itself? > > - Sean > _______________________________________________ > 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
