[openib-general] IPv6 and IPoIB scalability issue
Hal Rosenstock
halr at voltaire.com
Fri Dec 1 15:47:38 PST 2006
On Fri, 2006-12-01 at 18:17, Jason Gunthorpe wrote:
> On Fri, Dec 01, 2006 at 03:07:23PM -0500, Hal Rosenstock wrote:
>
> > > total of 2000*2005 (4,010,000) multicast member records in SA for fabric
> >
> > This is based on the above (which I'm not sure about) and is the worst
> > theoretical case, not the practical case.
>
> It isn't in the IB spec, but what would really help here is to be able
> to join a multicast prefix (more than 1 group with a single entry).
>
> Todd's option 1 optimization is then easially realized by having all
> IPv6 nodes join FF02::1:FF00:0/104 (all 2**24 multicast entries)
These are IPmc groups not IB mc groups though. I suppose you are asking
for the equivalent function in IB. When that subscribe is done, would it
automatically collapse to 1 MLID ? If that's what you mean, a spec
extension for this could be proposed and carried forward at the (IBTA)
MgtWG. Is there a special value of those 24 bits which is not used (and
could be used to indicate subscribe all) ? Or do you see another way to
indicate this ? There are some reserved bits at the end of
MCMemberRecord which could also be used to indicate this. That's
probably better.
> as
> full members. This provides interoperability between with stacks with
> this feature and without.
>
> Option 2 works better as well because all the nodes join
> FF02::1:FF00:0/104 as a send-only member on startup and then you only
> get N*2 multicast records to maintain.
>
> This also would improve the performance of IPv6 ND by not having to
> join/leave the SN groups for each ND query.
>
> IBA would have to be changed to support a prefix bits field in the
> MCMemberRecord structure though..
Is a full prefix needed or only 1 bit indicating join all ? If a prefix
is needed, it sounds like it is 24 bits in width. (That appears more
than what is available but I'll look more).
-- Hal
> Jason
More information about the general
mailing list