> > Actually, I was thinking about ditching the common response buffer and > > just overwriting the command buffer. > > The sgl approach allows this by letting user-space set the in and out > pointers to the same thing, without having problems with specifying > the out length or requiring user space to parse netlink to find the > reply. For common handling, the framework needs to know how much memory to allocate for copy in/out purposes. The location of the ioctl input data, and the resulting output response data, in the allocated buffer also need to be agreed upon by the framework and kernel client. Ideally, the number of calls to copy to/from user should be minimized. In my proposal, each ioctl is matched with a descriptor which defines the size of the kernel buffer needed for input/output, which is then allocated by the framework. I had the response buffer overwrite the command buffer, with the kernel client writing the response at the start of the kernel buffer. This is an area that needs discussion, but is at least separate from the uABI. Using an sgl for input would increase the number of copy from user calls. I anticipate the common case of the command header and command data located as part of the same memory buffer. If so, an input sgl would be less efficient. I want to avoid copying the header to get a length, then copying the sgl, and then copying the sgl data. Unless I'm missing something, using an sgl for output should work fine, and only adds a simple iterative loop into the code path. If we want to support more optimal ioctl handling, we could use separate ioctl commands for sgl versus non-sgl, with all other aspects of the two commands the same. - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
