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

[Christoph Lameter]

On Tue, 5 Oct 2010, Jason Gunthorpe wrote:

> > I agree. We had similar ideas. However, the kernel does send igmp
> > reports to the MC address not to 244.0.0.2. We would have to redirect at
> > the IB layer until multicast via MLID becomes functional. We cannot tell
> > when that will be the case.
>
> Sure, but Aleksey's patch is aimed at the case when the SM has not yet
> replied, not for your problem with IGMPv2. If their is no MLID then
> sending to the broadcast MLID is a better choice than hanging onto the
> packets. I wonder if you could even send unicasts to the broadcast?

The problem that the SM has not yet replied is no different between the
IGMP versions. If you get a confirmation but the MC group is not
functional then packets go nowhere.

> I still think the problem you have with IGMPv2 is best solved by
> leaning on the gateway vendors to support IGMPv3 - which *does* send
> all reports to 244.0.0.22

s/22/2

Certainly a solution for the igmp messages themselves but not for
initial traffic or traffic send via sendonly join.