[ewg] [PATCH] Make multicast and path record queue flexible.

[Jason Gunthorpe]

On Tue, Oct 05, 2010 at 03:43:47PM -0500, Christoph Lameter wrote:

> > Using .22 will generally solve the problems with sychronizing the
> > IPoIB gateway to the state of the IGMPv3 clients. Yes, there will
> > still be some unknown lag in building the IB side of the network and
> > for the router(s) to get ready to handle the group - but at least it
> > is no longer dependent on any timeouts.
> 
> How do you propose to handle the IB level join to 224.0.0.22 to avoid
> packet loss there? IGMP messages will still get lost because of that.

First, the routers all join the group at startup and stay joined
forever. This avoids the race in the route joining a new MGID after
the client creates it, but before the IGMPv2 report is sent. I expect
this is a major source of delay and uncertainty

Second, since all clients join this group as send-only it becomes
possible for the SM to do reasonable things - for instance the MLID
can be pre-provisioned as send-only from any end-port and thus after
the SM replies with a MLID the MLID is guaranteed good for send-only
use immediately.

Third, once the client etners IGMPv3 mode and joins the group (maybe
at system boot?) it stays joined forever.

Finally, by sending multicast packets to the broadcast during the time
the MLID is unknown we can pretty much guarantee that the first IGMPv3
packet that is sent to .22 will reach all routers in a timely fashion.
(Hence my objection to Aleksey's approach)

Basically, this completely solves the IGMP client to IPoIB router
communication problem. Yes, there will still be an unknown time until
the IB network, router, and whatever is beyond the router is ready to
actually process packets on a new group - BUT that is normal for IP
multicast! The main point is that without lost IGMP packets things can
proceed without relying on timeouts.

Jason