<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">
<TITLE>RE: [openib-general] Multicast address aliasing in IPoIB</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Roland Dreier [<A HREF="mailto:roland@topspin.com">mailto:roland@topspin.com</A>] </FONT>
<BR><FONT SIZE=2>> Sent: Friday, September 10, 2004 5:43 AM</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Dror> The problem is based on how Linux works. The IPoIB plugs</FONT>
<BR><FONT SIZE=2>> Dror> into the OS as an Ethernet driver. Therefore, it is subject</FONT>
<BR><FONT SIZE=2>> Dror> to the Ethernet rules, and from the OS, it only get lists of</FONT>
<BR><FONT SIZE=2>> Dror> "Ethernet" multicast addresses. The notification for</FONT>
<BR><FONT SIZE=2>> Dror> additional HW multicast address, will only be delivered to</FONT>
<BR><FONT SIZE=2>> Dror> the IPoIB driver if there is no Ethernet</FONT>
<BR><FONT SIZE=2>> Dror> aliasing. Otherwise, Linux will just maintain a reference</FONT>
<BR><FONT SIZE=2>> Dror> count per HW address. Therefore, there is a problem with the</FONT>
<BR><FONT SIZE=2>> Dror> implementation of the IPoIB driver as an Ethernet</FONT>
<BR><FONT SIZE=2>> Dror> driver. Fixing this problem requires a kernel patch (or a</FONT>
<BR><FONT SIZE=2>> Dror> very ugly solution).</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I see no reason to modify the IPoIB multicast mapping just </FONT>
<BR><FONT SIZE=2>> because the Linux kernel does not yet have support for it. </FONT>
<BR><FONT SIZE=2>> For customers that have to run older unpatched kernels, it is </FONT>
<BR><FONT SIZE=2>> possible to support the full IPoIB spec via ugly hacks (such </FONT>
<BR><FONT SIZE=2>> as the one found in the gen1 Topspin stack's IPoIB implementation).</FONT>
</P>
<P><FONT SIZE=2>Well, I am not sure that this solution works. It does peek into the</FONT>
<BR><FONT SIZE=2>full IP addresses when transmitting IP MC packets and when MC</FONT>
<BR><FONT SIZE=2>list update is triggered. However, when kernel just updates an existing</FONT>
<BR><FONT SIZE=2>entry in HW MC list by incrementing a ref count, it'll not call </FONT>
<BR><FONT SIZE=2>set_multicast_list() on the net_device. </FONT>
<BR><FONT SIZE=2>For example try registering to two aliasing addresses (register </FONT>
<BR><FONT SIZE=2>only: setsockopt(IP_ADD_MEMBERSHIP), but don't send a packet).</FONT>
<BR><FONT SIZE=2>You'll see that you end up being registered only to one address.</FONT>
<BR><FONT SIZE=2>This is the case where I feel that you'd need much uglier solution</FONT>
<BR><FONT SIZE=2>in order to make it work in gen1 stacks.</FONT>
</P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> For newer kernels, there is no reason that the IPoIB driver </FONT>
<BR><FONT SIZE=2>> has to masquerade at an ethernet driver -- we should be </FONT>
<BR><FONT SIZE=2>> aiming for a fully native driver that sets its dev->type </FONT>
<BR><FONT SIZE=2>> field to ARPHRD_INFINIBAND.</FONT>
</P>
<P><FONT SIZE=2>Gen 2, I strongly agree.</FONT>
</P>
</BODY>
</HTML>