> I followed the comments and your concerns and I'll try to address them all: > Let me start by making clear that EFA is not an infiniband device, nor it > aspires to being one, but I think it does fit the verbs model. I agree. It has the general abstract hardware semantics that I associated as 'verbs' - PD, MR, AH, QP, CQ. > We can implement an rdma-core (libibverbs) userspace provider with support for > standard UD (including the 40 bytes offset) and SRD QPs through direct verbs. > I'll also add documentation for SRD QP type, even if we end up using it as a > driver QP type. IMO, IB hardware semantic quirks should not carry over to more generic QP type definitions. EFA and IB have different addressing formats, so an app can't just switch between one UD QP and another. For comparison, RC QPs refer to a transport neutral reliable-connected QP. It went even further in that two RC QPs could use completely different CMs to setup the connection, or in the IB case, none at all! The feature set (e.g. atomics) supported by different RC transports aren't even the same. I still view SRD as a generic QP type for reliable-unconnected send and receive messages. In the EFA case, the max message size is limited to a single MTU, but other implementations may not have this limit. I don't see any benefit to hiding the real QP type behind a single driver defined value. Along this line, given the constraints of the existing APIs, if a reliable-unconnected QP that supported RDMA read/write were ever introduced, I would also add that as a new QP type. - Sean
