[openib-general] Multicast address aliasing in IPoIB

[Dror Goldenberg]

> -----Original Message-----
> From: Roland Dreier [mailto:roland at topspin.com] 
> Sent: Friday, September 10, 2004 5:43 AM
> 
> 
>     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).

Well, I am not sure that this solution works. It does peek into the
full IP addresses when transmitting IP MC packets and when MC
list update is triggered. However, when kernel just updates an existing
entry in HW MC list by incrementing a ref count, it'll not call 
set_multicast_list() on the net_device. 
For example try registering to two aliasing addresses (register 
only: setsockopt(IP_ADD_MEMBERSHIP), but don't send a packet).
You'll see that you end up being registered only to one address.
This is the case where I feel that you'd need much uglier solution
in order to make it work in gen1 stacks.

> 
> 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.

Gen 2, I strongly agree.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20040913/ff350356/attachment.html>