[openib-general] RDMA connection and address translation API

Roland Dreier rolandd at cisco.com
Wed Aug 24 14:23:43 PDT 2005


    James> You need to consider what makes sense for *both* ib and
    James> iwarp. Keep in mind that the correct API will allow a
    James> consumer to use ib and iwarp devices transparently. In
    James> other words their will be one code path that support both.

    James> If we were to adopt your proposal, the consumer would need
    James> to perform unnecessary operations on iWARP.

No, I think we just need to realize that a perfectly transport neutral
protocol implementation is not achievable.  It's unfortunate that
kDAPL fooled people by hiding the details of the wire protocol under a
supposedly "neutral API," but the fact is that mapping an abstract
RDMA transport to a real implementation will always involve arbitrary
transport-dependent choices.

To use an analogy, the IP layer is mostly insulated from the details
of the L2 transport it's using by the net_device abstraction.
However, there are a few things that require code like:

	int arp_mc_map(u32 addr, u8 *haddr, struct net_device *dev, int dir)
	{
		switch (dev->type) {
		case ARPHRD_ETHER:
		case ARPHRD_FDDI:
		case ARPHRD_IEEE802:
			ip_eth_mc_map(addr, haddr);
			return 0; 
		case ARPHRD_IEEE802_TR:
			ip_tr_mc_map(addr, haddr);
			return 0;
		case ARPHRD_INFINIBAND:
			ip_ib_mc_map(addr, haddr);
			return 0;
		default:
			if (dir) {
				memcpy(haddr, dev->broadcast, dev->addr_len);
				return 0;
			}
		}
		return -EINVAL;
	}

 - R.



More information about the general mailing list