On Fri, Apr 26, 2013 at 12:40 AM, Jason Gunthorpe wrote: > As Sean said earlier, please think about a single QP, multiple RQ/SQ > style API - that seems much more general to me and also could > reasonably be defined for other transport types.
I find it to have too much of an abstraction for kernel level API, since that single QP isn't really a HW construct but rather something artificial. For UD/RAW PACKET QPs, RSS is natual and done on maybe > 100 Ethernet NIC drivers, where a special steering rule sends RX packet to a dispatcher QP who applies hash and does 2nd dispatching to QPs/rings depending on the hash results, so now we want to bring that to IPoIB too, and we allow to specify that "parent" etc etc. Or. > > For instance, someday supporting multiple RQ on a RC transport, with > content-based steering, is a limited form of tag matching.. From a > longer-term user space API design standpoint the concept seems to have > more longevity. > > Also, I feel what happens inside the kernel is more flexable API > wise, so dropping the uverbs component may also be something you want > to look at. > > Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
