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. You can do multicast on UC QP. You can't do multicast on RC QP. BTW In your first patch looks like you are doing htonl when you should be doing htons (or cpu_to_be16 which is good with constants) > -----Original Message----- > From: Christoph Lameter [mailto:c...@linux.com] > Sent: Monday, August 23, 2010 22:28 > To: Jason Gunthorpe > Cc: linux-rdma@vger.kernel.org; Or Gerlitz; Yossi Etigin; Roland Dreier > Subject: Re: IPoIB: Broken IGMP processing > > On Mon, 23 Aug 2010, Jason Gunthorpe wrote: > > > src_qp is just the send QPN, you need to look at qp_num (aka dest qp). > > I'm not entirely sure what it will be, I didn't find anything too clear > > in the spec. If it is 0xFFFFFF then the HCA is copying the dest QP > > directly into the WC and this can work, if it is something else then > > the HCA is setting it to the QPN of the RQ that recieved the packet, > > which is not useful for this. > > AFAICT the spec has a QP for RC and one for UD packets. How do these > relate to multicast? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
