[openib-general] ib_gid_is_link_local

[Hal Rosenstock]

On Thu, 2007-01-04 at 18:58, Jason Gunthorpe wrote:
> On Thu, Jan 04, 2007 at 05:13:52PM -0500, Hal Rosenstock wrote:
> 
> > > The way I was hoping to start out is by putting this in the SA and the
> > > routers, not in the end nodes.
> > 
> > We can start there but this is a very fundamental question. I have heard
> > people weigh in on both sides...
> 
> Yes, but fortunately the two methods can co-exist and we can prototype
> the expected router support in opensm and get some experience
> there.

True.

> > > With this kind of model the IB path lookup would return a LID/SL/etc
> > 
> > Map S/DGID and perhaps TClass to LID/SL/MTU ?
> 
> Yeah, I think so.
> 
> > all known MLIDs on that subnet rather than all possible MLIDs ? It's
> > really the MGIDs that are of interest rather than the MLIDs. The router
> > needs to subscribe to traps 66/67 multicast groups in and out of
> > existence. MLIDs on each side of the router may not be the same for a
> > non link local MGID.
> 
> Yes, we can definately do that.
> 
> However, it might be smart to have opensm consider the routers to be a
> send-only member for every MLID..

Do you mean non-member rather than send-only member ? Routers need to
receive as well as send, right ? Or are you worried about some other
issue here ?

Also, I'm still not sure about a couple of aspects of "every MLID":
1. Wouldn't the router only want to be full member of link local scoped
MGIDs (that it was interested in locally) ? Are you saying any local
scoped MGIDs not of interest would just get dropped anyhow ? If that is
the point here, that would work but isn't there a performance impact of
doing so ? 
2. Similarly for any other (non local scope) MGRPs which do not match
across any router ports, isn't there a performance impact of receiving
and then having to drop/filter these packets ?

> > By onlink, are you saying these wouldn't be forwarded ?
> 
> Not necessarily, the resulting MLID could still end up going to a
> router.. 

Right, the router is some sort of member on the MGRPs "of interest". I
think you are trying to make that list of MGRPs "of interest" simpler
and utilize filtering where not needed (as I mentioned above), but I may
be mistaken here.

> A onlink line routing table just terminates the routing
> lookup. 'unreachable' is another termination. A via line changes the
> next hop GID and creates more lookups until an onlink is reached.

So is the specification of all multicast as onlink a short term thing
then ?

Also, with using onlink for all multicast, is there some forwarding
determination made somewhere in the router stack ?

> I honestly don't have a good idea how routed multicast can work on IB
> without alot of ugly overhead. What do you do if you route between 4
> 1000 node clusters with IPv6? How can you avoid registering 4000
> multicast groups with each SM and still have IPv6 SNM work correctly?

Yes, I have no idea how IPv6 will work with large inter subnet clusters
either. We had a thread on this a while ago and I think it died out at
that point. To state the obvious, I think some changes need to be made
for IPv6 to work well with current IB hardware or perhaps some
configuration restrictions ?

> > Are you referring to running a spanning tree for multicast ? In any
> > case, I think it will be a while before the routing protocols come into
> > the picture and whether the SM is involved or not is another piece of
> > some of the fundamental routing questions/devisions to be made.
> 
> Yes, but in this case I don't think multicast routing can be pushed to
> the host. It is either the router or some combination of the router
> and the SM.

I'm not quite following you on this yet. Why/how is host multicast
routing any different (than unicast) ?

-- Hal

> Jason