[openib-general] Multicast address aliasing in IPoIB

Roland Dreier roland at topspin.com
Thu Sep 9 19:43:29 PDT 2004


    Dror> The problem is based on how Linux works. The IPoIB plugs
    Dror> into the OS as an Ethernet driver. Therefore, it is subject
    Dror> to the Ethernet rules, and from the OS, it only get lists of
    Dror> "Ethernet" multicast addresses. The notification for
    Dror> additional HW multicast address, will only be delivered to
    Dror> the IPoIB driver if there is no Ethernet
    Dror> aliasing. Otherwise, Linux will just maintain a reference
    Dror> count per HW address. Therefore, there is a problem with the
    Dror> implementation of the IPoIB driver as an Ethernet
    Dror> driver. Fixing this problem requires a kernel patch (or a
    Dror> very ugly solution).

I see no reason to modify the IPoIB multicast mapping just because the
Linux kernel does not yet have support for it.  For customers that
have to run older unpatched kernels, it is possible to support the
full IPoIB spec via ugly hacks (such as the one found in the gen1
Topspin stack's IPoIB implementation).

For newer kernels, there is no reason that the IPoIB driver has to
masquerade at an ethernet driver -- we should be aiming for a fully
native driver that sets its dev->type field to ARPHRD_INFINIBAND.

Once the OpenIB IPoIB driver is ready to be merged upstream, it should
be no problem to get the trivial changes required in the core
networking code merged.  As far as I can tell, the only changes needed
would be: implement an ip_ib_mc_map() function and add

	case ARPHRD_INFINIBAND:
		ip_ib_mc_map(addr, haddr);
		return 0;

to arp_mc_map() in net/ipv4/arp.c and to make the analogous addition
for ndisc_mc_map() in net/ipv6/ndisc.c.  (ARPHRD_INFINIBAND is already
defined in the Linux headers -- I got that merged back in early 2003)

 - R.



More information about the general mailing list