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

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

On Tue, Oct 12, 2010 at 06:29:53PM +0200, Alekseys Senin wrote:
> On Tue, 2010-10-05 at 14:12 -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.
> 
> But what if it will not be available from some reason? How long
> should we wait?  Do we need implement another queue/counter/timeout?

If you follow the scheme I outlined - where traffic to a MGID that
doesn't yet have a MLID is routed to the broadcast MLID then you do it
until you get a MLID, with periodic retries/refreshes of the SA
operation.

This is similar to how ethernet works, and is generally
harmless. Better to have a working, but suboptimal network, than one
that is busted.

Jason