On 13/Dec/09 18:23, Sasha Khapyorsky wrote:
On 12:32 Sun 06 Dec , Yevgeny Kliteynik wrote:
@@ -1096,7 +1106,15 @@ int osm_sa_db_file_load(osm_opensm_t * p_osm)
}
}
- if (!rereg_clients)
+ /*
+ * If restoring SA DB is required only once, SM should go
+ * into the usual mode right after that, which means that
+ * client re-registration should be required even after
+ * the restore - there is a chance that OSM died right after
+ * some MCMember joined MCast group, and his membership
+ * didn't make it into the SA DB file.
+ */
+ if (!p_osm->subn.opt.sa_db_load_once&& !rereg_clients)
p_osm->subn.opt.no_clients_rereg = TRUE;
Hmm, if you are going to request clients reregistration unconditionally
then what is the reason to restore SA DB?
Maybe you wanted to switch this flag off *after* first sweep, but I'm
not sure following your comment.
We have a dump file with mcast members, and OSM is loading
this file. Suppose OSM has successfully loaded the whole file.
But this does not mean that there's no need to request client
re-registration on all the hosts. Consider the following case:
- Heavy sweep - SM dumps current SA DB to a file
- Client asks to join some mcast group
- SM gets the request and processes it
- The request is OK - SM sets the 'dirty' flag and
responds to client
- Client gets the response
- SM dies
- SM is restarted - it loads the existing SA DB, which
does not includes the latest client's membership
- Loading of the whole SA DB is OK - no client re-register
request is issued
- Client remains disconnected from the mcast group
It is easy to think about such or similar scenarios. But OTOH if you
are going to request clients reregistration, why to preload SA DB?
I want to be able to tell SM to request client re-register
after loading the SA DB even if all was OK.
So my question is when preloading SA DB buys something for us when
clients will reregister anyway? Bugs?
Well, I wouldn't call it "bugs". It's more of non-compliant
application behavior. Many applications just not able to
survive things like MLID change - they are not listening
to events and do not request mcast group re-registration.
-- Yevgeny
So there are 3 options to do it:
1. Completely rely on 'no_clients_rereg' option only.
Do not alter this option, doesn't matter if the SA DB
reloading succeeded or not.
2. Combine 'no_clients_rereg' option with loading SA DB
result: if loading succeeded, do whatever 'no_clients_rereg'
option says. If loading failed at some point, turn off
the 'no_clients_rereg' option (turn on re-registartion
requests, don't you just love the double-negative logic?)
3. Add new option for this particular case.
I'm all for option 2, and this is what I'm implementing
in V3 series patches.
IMHO this is better than what was proposed in the original patch. Think
that we can make it this way.
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
