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 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html