[ofa-general] [RFC] host stack IB-to-IB router support

[Hal Rosenstock]

On Wed, 2007-03-21 at 08:00, Diego Crupnicoff wrote:
> > -----Original Message-----
> > From: general-bounces at lists.openfabrics.org [mailto:general-
> > bounces at lists.openfabrics.org] On Behalf Of Jason Gunthorpe
> > Sent: Wednesday, March 21, 2007 1:32 AM
> > To: Yaron Haviv
> > Cc: general at lists.openfabrics.org
> > Subject: Re: [ofa-general] [RFC] host stack IB-to-IB router support
> > 
> > On Wed, Mar 21, 2007 at 04:21:15AM +0200, Yaron Haviv wrote:
> > 
> > > I believe a much simpler and more generalized solution would be to
> > > imitate the behavior of IP routing rather than using the "remote sa"
> > > concept
> > 
> 
> I completely agree with Yaron.
> 
> > We talked about this at some length a while ago on this list. In
> > short, we started with the position you outlined until it was
> > discovered that the L2 address checking described by 9.6.1.5.1 C9-57
> > makes it unworkable. This existing IB behavior is sufficiently
> > un-IP-like that existing IP solutions do not work. (The parallel to
> > ethernet would be if each TCP connection checked that the SMAC in
> > incoming frames matched some pre-determined value.)
> 
> If C9-57 is a problem then that can be addressed by the IBTA. 
> BTW, the IBTA is going to present on IB routers spec during the upcoming
> OFA workshop in Sonoma. That should be a good opportunity for non-IBTA
> members to raise their concerns and potentially find ways to become
> involved in the router architecture specification process. 
> 
> > 
> > Sean is working on one of the simpler solutions that considers the
> > effects of C9-57, which is to allow the active side to control all 4
> > path records that are involved.
> > 
> > Notice this is similar to how IB CM works within a subnet, where the 2
> > required paths are selected by the active side and the passive side
> > does no queries. This already is different than IP which would have
> > the passive side doing ARP. Again this behavior in the spec is
> > fundamentally required by the restriction in C9-57.
> 
> For the IB spec, the SM and SA are subnet local entities. The remote SA
> concept is at odds with the spirit of the IB spec. I would say that
> changing that is a much more significant departure from the spec than
> dealing with C9-57 if necessary.

The SM is subnet local but it is unclear about the SA. Currently, if one
knows the GID of the SA, it can be contacted remotely. To support
routing, there are a number of things that SA supports that I think will
need to be exchanged across SAs so in this sense it may not be that far
off in that it separates this aspect which can evolve to wherever it
ends up in the architecture. It is a temporary measure to get by with
the lack of specificity in the routing space. As you can see, there is
an immediate need within OpenFabrics to resolve these issues or at least
take an experimental stab at them so more IB router protoyping can be
done.

-- Hal

> > I agree with you that this is not a good place to be, but with current
> > hardware I think we are stuck with it..
> 
> I do not think so (with my ib hw asic vendor hat on). 
> 
> > 
> > Regards,
> > Jason
> > _______________________________________________
> > general mailing list
> > general at lists.openfabrics.org
> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> > 
> > To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-
> > general
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general