Similar hint to the NFS over RDMA folks at CITI - if you want your stuff to go in use the openib helper directly below the transport switch - differnet RDMA transports are too diverse to be sanely abstracted out and DAPL does a horrible job at that. If we need to consolidate code for differnt transports we can put it into a library later on.
CITI folk here.
I'm not familiar with the openib helper you refer to, but since you mention the transport switch, I'll assume you're referring to the client. I'm currently working on the NFS over RPCRDMA server, so this isn't of much help to me.
While I'd agree that DAPL has it's shortcomings, it's not finalized yet, and I know of no other alternatives. On the other hand, I don't agree that the different RDMA transports are necessarily too diverse to provide a reasonable API for them. It seems silly to invest a lot of effort writing directly for IB, since we couldn't reuse the code for other transports. Why create a nonstandard library after the fact when so much work has gone into DAPL already? Even if DAPL needs to change, we can later make our changes just once at that layer.
We should have basic functionality with NFS atop DAPL in the near future that will enable us to plug in different transports without changing the ULP code. Would that convince you that DAPL is at least a useful starting point?
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
