> Unfortunately for IB the size of an RMPP response and buffer cannot > be controlled by the kernel. So if an application has a large > response to send, the entire buffer must be copied into the kernel > and the kernel cannot decide on its own segmentation boundaries. > Hence the ability for selected management applications to control and > limit the amount of kernel memory space is desirable. These issues > become serious at scale when larger RMPP responses are needed and > more clients may also be issuing requests. The two can combine and > result in N^2 types behavior for kernel memory footprint relative to > N=cluster node count or potentially N=cluster CPU core count.
So this is an interesting point. However I don't think we really want to solve this by adding some magic value of the version field that changes the umad interface into a completely different mode and then have every app implement its own copy of the RMPP protocol in userspace. It would seem a lot cleaner to me to just fix up the kernel RMPP implementation to avoid the huge double buffering; is that not possible? The other argument (proprietary legacy apps) doesn't really carry any weight with me. We're not going to introduce duplicate APIs just so someone doesn't have to port old code. - R. -- Roland Dreier <[email protected]> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
