On Wed, Jul 1, 2009 at 4:00 PM, Jason Gunthorpe<jguntho...@obsidianresearch.com> wrote: > On Wed, Jul 01, 2009 at 03:39:01PM -0400, Hal Rosenstock wrote: > >> > Clearly the only sane way this can work is if the GID is always >> > filled in for the redirection case. >> >> Why is that ? Why must the redirector provide GRH info when it's not >> required for subnet local cases ? > > Because the redirector doesn't know what the initiator will do. It > could include a GRH, or maybe not. It must include the GID to cover > both cases.
It could restrict what the initiator can do by doing this. Nothing wrong with that AFAIT. I agree that this is not what you'd want if the requester were not subnet local. I'm only talking about the subnet local case. >> >> Futhermore, RedirectLID can be non zero but GID redirection is still >> >> being used as indicated by the RedirectLID description indicating that >> >> a non zero RedirectLID will in general not be valid. >> > >> > The spec says if it is not zero the requester shall use it. I don't >> > see an ambiguity here. >> >> To me, the ambiguity is several lines below it where it states that >> the RedirectLID might not be valid and says to obtain a PathRecord >> when RedirectGID is supplied rather than relying on the RedirectLID is >> non zero. > > Whoever authored this should not have mixed 'will in general not be > valid' and 'they must be replaced' in the same sentance - but I think > the meaning is still clear. With a 0 RedirectLID only the RedirectGID, > QP and P_Key are to be used by the receiver. When RedirectLID is not 0 > then all of the Redirect fields must contain correct data and should > be used as necessary by the receiver. > > It never says to obtain a Path Record when a GID is supplied. It says > to obtain a path record with RedirectLID is 0. In looking at this some more, I agree with you on this part now since all that text is part of the RedirectLID 0 paragraph. -- Hal > Jason > _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg