[ewg] OFED-1.5.1 failure over iWarp

Sean Hefty sean.hefty at intel.com
Mon Feb 1 17:23:40 PST 2010


>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




More information about the ewg mailing list