[openib-general] Problem is routing CM REQ

Jason Gunthorpe jgunthorpe at obsidianresearch.com
Fri Feb 9 16:48:20 PST 2007


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!




More information about the general mailing list