On Fri, Feb 09, 2007 at 03:08:12PM -0800, Sean Hefty wrote: > The route itself is determined using the SGID, DGID, TClass, FlowLabel. > So, as long as the two queries match on these fields, I would think that it > would work.
So basically what you are saying is that the TClass and FlowLabel act as some kind of global dis-ambiguation that lets all SAs know that the tuple <SGID,DGID,TClass,FlowLabel> MUST be matched with <LRH_A,LRH_B> on each side. I can see how this can work, but I think it has big implications, like global SA database sharing, maybe larger router tables, or limited router multipath, etc. [1] I've been thinking that the <SGID,DGID,TClass,FlowLabel> tuple would only reflect 2 of the 4 lids (ie the ones the router chooses on entry to the final subnet). I personally can't see anything discussed so far as a slam dunk answer to this broader problem. The very simple reversible paths only solution still seems best to me only because it involves the least work and only requires that IBA specify routed reversible paths. The only missing bit is a way to signal that the target should have this behavior in the REQ message. Perhaps something like setting the DLID in the REQ to 0xFFFF? Jason [1] - Interestingly with this scheme the first PR query must select all 4 LIDs (although it may not know what they are..). The PR itself would return the first two local LIDS and those would also have to be encoded in the GRH. The 2nd remote PR would recover those LIDs from the GRH to build the return GRH. Since routers route based on GRH every GRH also encodes the destination LIDs too! _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general