> You are right that the most of the speed-up is coming from avoid semaphores, > but not only. > > From the oprof traces, the semaphores made half of difference. > > The next one was copy_from_user and kmalloc/kfree usage (in my proposal - > shared page method is used instead)
OK, but in any case the switch from idr to hash table seems to be insignificant. I agree that using a shared page is a good idea, but removing locking needed for correctness is not a good optimization. > In my opinion, the responsibility for cases like protection of QP > against destroy during buffer post (and other similar cases) should > be moved to vendor driver. The OFED code should move only the code > path to driver. Not sure what OFED code you're talking about. We're discussing the kernel uverbs code, right? In any case I'd be interested in seeing how it looks if you move the protection into the individual drivers. I'd be worried about having to duplicate the same code everywhere (which leads to bugs in individual drivers) -- I guess this could be resolved by having the code be a library that individual drivers call into. But also I'm not sure if I see how you could make such a scheme work -- you need to make sure that the data structures used in the uverbs dispatch to drivers remain consistent. In the end I don't think we should go too far optimizing the non-kernel-bypass case of verbs -- the main thing we're designing for is kernel bypass hardware, after all. Perhaps you could make your case go faster by using a different file descriptor for each QP or something (you could pass the fd back as part of the driver-specific create QP path)? - R. -- 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
