> This looks very similar to the libaio interface.. I did look at aio. It may be possible to use aio context in place of ioq, and I'm open to that. I was actually modeling ioq more after epoll than aio. It just seemed simpler to treat an ioq as a standard fd. For the get/put calls, there's no requirement to use asynchronous or nonblocking I/O. When asynchronous operations are used, restricting each socket to a single, persistent ioq thingy simplifies the implementation by making the mapping between an ioq and HW CQs easier to manage.
My concern is that supporting a more flexible API, like aoi, would effectively result in losing some desirable feature handling completions, such as kernel bypass or reducing interrupts. With aio, I'm unsure about the impact of supporting callback notifications and the selection of each aio context on a per request basis. - Sean -- 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
