>core_0450_ib_core-RoCEE-CMA-device-binding.patch >This modifies the rdma_cm path for RoCEE. It includes this change: > >static inline void rdma_addr_get_sgid(struct rdma_dev_addr *dev_addr, union ib_ >gid *gid) > { >- memcpy(gid, dev_addr->src_dev_addr + rdma_addr_gid_offset(dev_addr), >siz >eof *gid); >+ if (dev_addr->transport == RDMA_TRANSPORT_IB && >+ dev_addr->dev_type != ARPHRD_INFINIBAND) >+ rocee_addr_get_sgid(dev_addr, gid); >+ else >+ memcpy(gid, dev_addr->src_dev_addr + >+ rdma_addr_gid_offset(dev_addr), sizeof *gid); > }
>if (dev_addr->transport == RDMA_TRANSPORT_IB && > dev_addr->dev_type == ARPHRD_ETHER) After trying to read through the patches more, the rocee patches don't seem appropriate for a 'point' release, but, anyway... It appears that the dev_type is ARPHDR_ETHER. Is this correct, or should a different dev_type be used? Maybe some sort of mapping from ARPHDR_* dev_type to an RDMA device type is needed in ib_addr, possibly in rdma_copy_addr(). Looking at a struct net_device, how do we know what kind of RDMA device we have if the ARPHDR dev_type isn't sufficient? For the call to rdma_addr_get_sgid(), maybe the name or purpose of that call needs to be changed, with a second call being added. What cma_acquire_dev() wants is a local device address so that it can match the net_device up with the ib_device. Perhaps there's a cleaner way to do this than calling rdma_addr_get_sgid() from cma_acquire_dev(). Along these same lines, why can't the 'sgid' be incorporated into the src_dev_addr, similar to what is done for iwarp devices? I don't really understand the function rocee_mac_to_ll(), and maybe it's just the name. I'm assuming that 'll' stands for link-layer, correct? Since the MAC address is a link-layer address, what layer is the GID? In the short term, can someone please try testing iwarp with the if statement mentioned above changed as indicated (i.e. != ARPHRD_INFINIBAND becomes == ARPHDR_ETHER)? If no one else can try it, I may be able to do it tomorrow or Wednesday if I can figure out Woody's build process, since he's on vacation. - Sean _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg