As mentioned in the past, client reregistration is a rather large
hammer. There have been discussions on utilizing this mechanism in more
scenarios (which FWIW is not a good thing IMO). This approach (and it is
optional) pushes the burden back on the end nodes rather than the SM.
Scalability is certainly an issue with it. It was begrudgingly put into
the spec. It was intended only as a stopgap measure.
There was informative text put into the spec alluding to the
"appropriate" use of this option:
"A reason for the SM doing this might be that the SM suffered a failure
and as a result lost its own records of such subscriptions."
This is referring to a single SM (although that is not the recommended
deployment topology) crashing and being restarted.
IMO a civil SM would not rely on this mechanism.
There's still the problem that the ULPs on the end-node do not know when
or if the data is lost. IMO, making client reregistration mandatory
would have been a better solution, allowing ULPs to only re-register on
that event. As it stands now, ULPs automatically reregister on SM LID
changes, port events, etc.. In order to avoid ULP re-registration, SM
failover has to bring along the LID.
An alternate solution could have let an SM learn what it needed from the
end nodes through queries...
- Sean
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
