[openib-general] Problem is routing CM REQ was: Use a GRH when appropriate for unicast packets

[Michael Krause]

At 12:39 PM 2/8/2007, Hal Rosenstock wrote:
>On Thu, 2007-02-08 at 14:54, Sean Hefty wrote:
> > >Hum, you mean to meet the LID validation rules of 9.6.1.5? That is a
> > >huge PITA..
> > >
> > >[IMHO, 9.6.1.5 C9-54 is a mistake, if there is a GRH then the LRH.SLID
> > > should not be validated against the QP context since it makes it
> > > extra hard for multipath routing and QoS to work...]

If you examine the prior diagram, the packet validation is quite precise 
and intent on catching any misrouted packets as early in the validation 
process as possible.  This particular compliance statement makes it clear 
as to the type of connection and how to pattern match.  The protocol was 
designed to work witin a single subnet as well as across subnets.  Hence, 
the GRH must be validated in conjunction with the LRH and the QP context in 
order to insure an intermediate component did not misroute the 
packet.    As described, a RC QP must flow through at most a single path at 
any given time in order to insure packet ordering is maintained (IB 
requires strong ordering so multi-path within a single RC is not 
allowed).   As for QoS, one can arbitrate a packet for a RC QP relative to 
other flows without any additional complexity.   If one wants to segregate 
a set of RC QP onto different paths as well as arbitration slots that is 
allowed and supported by the architecture even if going between the same 
set of ports - simply use multiple LID and SL during connection 
establishment.

Mike

> >
> > Yes - this gets messy.
> >
> > >Here is one thought on how to do this:
> > >To meet this rule each side of the CM must take the SLID from
> > >the incoming LRH as the DLID for the connection. This SLID will be
> > >one of the SLIDs for the local router. The other side doesn't need to
> > >know what it is. The passive side will get the router SLID from the
> > >REQ and the active side gets it from the ACK.
> > >
> > >The passive side is easy, it just path record queries the DGID and
> > >requests the DLID == the incoming LRH.SLID.
> >
> > This requires that the passive side be able to issue path record 
> queries, but I
> > think that it could work for static routes.  A point was made to me 
> that the
> > remote side could be a TCA without query capabilities.
>
>Are you referring to SA query capabilities ? Would such a device just be
>expected to work without change in an IB routed environment anyway ?
>
>-- Hal
>
> >
> > There's still the issue of what value is carried in the remote port LID 
> in the
> > CM REQ (12.7.21), and I haven't even gotten to APM yet...
> >
> > >The nasty problem is with the active side - CMA will select a router
> > >lid it uses as the DLID and the router may select a different LID for
> > >it to use as the SLID when it processes the ACK. By C9-54 they have to
> > >be the same :< So the active side might have to do another path record
> > >query to move its DLID and SL to match the routers choosen
> > >SLID. Double suck :P
> >
> > As long as the SA and local routers are in sync, we may be okay here 
> without a
> > second path record query.
> >
> > - Sean
> >
> > _______________________________________________
> > openib-general mailing list
> > openib-general at openib.org
> > http://openib.org/mailman/listinfo/openib-general
> >
> > To unsubscribe, please visit 
> http://openib.org/mailman/listinfo/openib-general
> >
>
>
>_______________________________________________
>openib-general mailing list
>openib-general at openib.org
>http://openib.org/mailman/listinfo/openib-general
>
>To unsubscribe, please visit 
>http://openib.org/mailman/listinfo/openib-general