Re: [patch v2 02/37] add opcodes to ib_pack.h

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Wed, Aug 31, 2011 at 10:15:02PM -0500, Bob Pearson wrote:

> > 1. Using ipv6_eth_mc_map() for mapping multicast GIDs seems an
> > unfortunate choice to me. That choice will cause multicast GIDs to be
> > mapped to the 33-33-xx-xx-xx-xx Ethernet address range that has been
> > reserved by RFC 2464 for IPv6 multicast addresses. If a collision with
> > an IPv6 multicast address occurs and IPv6 MLD snooping has enabled on
> > the switches in the involved network then RoCE multicast won't work
> > properly. IMHO we need a separate Ethernet address range for RoCE
> > multicast purposes, next to the existing ranges for IPv4 and IPv6.
> 
> I thought this was intentional! I.e. in order to get multicast over RoCE to
> work we were trying to piggyback on the behavior of intelligent switches.
> Otherwise the only way to get packets forwarded without adding a new group
> of multicast addresses would be to broadcast. The implementation of IGMP and
> MLD at the end node is oblivious to the packet's ethertype. And switches (at
> least the ones we tried) also happily multicast RoCE packets.

Nothing about RoCE multicast is standardized or even proposed to be
standardized.

Hijacking the IPv6 MAC space - and also abusing the net stack to
generate MLD stuff is what Mellanox did in their implementation. I
don't know if that was included in the main line submission or not?

Frankly I'd be inclined to map to the broadcast MAC address to pressure
the relevant standards bodies to finish the work on RoCE.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html