> 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
