Re: [PATCH] Make multicast and path record queue flexible.

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Tue, Oct 05, 2010 at 02:12:57PM -0500, Christoph Lameter wrote:
> On Tue, 5 Oct 2010, Jason Gunthorpe wrote:
> 
> > On Tue, Oct 05, 2010 at 06:07:37PM +0200, Aleksey Senin wrote:
> > > When using slow SM allow more packets to be buffered before answer
> > > comming back. This patch based on idea of Christoph Lameter.
> > >
> > > http://lists.openfabrics.org/pipermail/general/2009-June/059853.html
> >
> > IMHO, I think it is better to send multicasts to the broadcast MLID than to
> > queue them.. More like ethernet that way.
> 
> 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?

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

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html