[openib-general] ip_ib_mc_map?

[Michael S. Tsirkin]

>  From a reason that no one at RH can trace... someone went and removed 
> all the support for ARPHRD_INFINIBAND multicast from u4 where it exists 
> perfectly fine in u3 and hopefully on u5 as well (Doug can you update?), 
> see https://bugs.openfabrics.org/show_bug.cgi?id=2661
> 
> Specifically, the below snip from the patch means that on rh4 u4 all 
> IPv4 ARPHRD_INFINIBAND multicast goes on the broadcast group !!!
> 
> > Index: linux-2.6.9/net/ipv4/arp.c
> > ===================================================================
> > --- linux-2.6.9.orig/net/ipv4/arp.c	2004-10-18 23:55:06.000000000 +0200
> > +++ linux-2.6.9/net/ipv4/arp.c	2006-09-20 14:43:59.000000000 +0300
> > @@ -213,6 +213,9 @@
> >  	case ARPHRD_IEEE802_TR:
> >  		ip_tr_mc_map(addr, haddr);
> >  		return 0;
> > +	case ARPHRD_INFINIBAND:
> > +		ip_ib_mc_map(addr, haddr);
> > +		return 0;
> >  	default:
> >  		if (dir) {
> >  			memcpy(haddr, dev->broadcast, dev->addr_len);
> 
> anyway, OFED wise, i see two ways to solve this:
> 
> 1) adding a backport to the rdma_cm containing ip_ib_mc_map, period.
> 
> This means that apps offloading multicast traffic through the rdma cm 
> would use the correct group where apps working through the net stack
> use the broadcast group.
> 
> 2) having the rdma cm follow the net stack and make its consumer use the 
> broadcast group.

Correct. Since multicast is broken in other respects on U4
(sockets can't join multicast groups), I think 2 is the simplest approach.

Anyone who wants IPoIB milticast should just stay away from U4.

-- 
MST