[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