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.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
