Re: IPoIB: Broken IGMP processing

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

On Mon, Aug 23, 2010 at 10:34:38PM +0300, Yossi Etigin wrote:
> Hello Christoph,
> 
> I think you'll first want to check the wc_flags field in the work
> completion to see whether GRH is present (and it must be present in
> multicast packets, normally not present in unicast). Then, extract the
> destination gid from grh, and compare the first 6 bytes of it to the
> dev->broadcast address bytes 4...9 (once with dev->broadcast which is
> IPv4, second time with dev->broadcast with the IP version nibble changed
> to 6). The first 4 bytes of dev->broadcast are QPN.
> Of course, you'll be doing this before pulling any other headers from
> the skb because GRH comes first.

> The QPN you get in the completion is the QP from which it was sent -
> src_qp. You don't get the QPN which was put in the UD header by the
> sender, which is 0xFFFFFF for multicast. In userspace (aka struct
> ibv_wc), you get the qp number from which the receive buffer was taken,
> and in kernel space (aka struct ib_wc, no 'v') you get the pointer to
> the QP.

Ah, so that clears things up. Sorry to have confused things with this
suggestion.

Simplest then is to check if byte 24 of the packet is 0xff.
(ie IN6_IS_ADDR_MULTICAST)

No need to worry about if it is properly formed or anything, if it is
a multicast DGID then it is a multicast packet at the link level.

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