> Just to clarify, when saying "achieved performance comparable to > previous solution" you refer to the approach which bypasses uverbs on > the post send path? Also, why enhance only the raw qp flow?
I compare to my previous solution using private device for passing information about packets. Comparing to current approach I see more than 20% of improvement. This solution introduces a new path for posting buffers using a shared page approach. It works following way: 1. create RAW qp and add it to the raw QP hash list. 2. user space library mmaps the shared page (it is specific action per device and must implemented separately per each driver) 3. during buffer posting the library puts buffers info into shared page and calls uverbs. 4. uverbs detects the raw qp and inform the driver bypassing current path. The solution cannot be shared between RDMA drivers because it needs redesign of the driver (share page format is vendor specific). Now only NES driver implements the RAW QP path through kernel (other vendors uses pure user-space solution) so No other vendor will use this path. There is possibility to add a new QP capability or attribute that will inform uverbs that it is a new transmit path used so then the solution could be extended for all drivers. Mirek -----Original Message----- From: Or Gerlitz [mailto:ogerl...@voltaire.com] Sent: Monday, December 27, 2010 4:22 PM To: Walukiewicz, Miroslaw Cc: Jason Gunthorpe; Roland Dreier; Hefty, Sean; linux-rdma@vger.kernel.org Subject: Re: ibv_post_send/recv kernel path optimizations On 12/27/2010 5:18 PM, Walukiewicz, Miroslaw wrote: > I implemented the very small hash table and I achieved performance > comparable to previous solution. Just to clarify, when saying "achieved performance comparable to previous solution" you refer to the approach which bypasses uverbs on the post send path? Also, why enhance only the raw qp flow? Or. -- 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
