On Tue, 2013-06-11 at 09:49 +0300, Eliezer Tamir wrote: > I would like to hear opinions on what needs to be added to make this > feature complete. > > The list I have so far is: > 1. add a socket option
Yes, please. I do not believe all sockets on the machine are candidate for low latency. In fact very few of them should be, depending on the number of cpu and/or RX queues. > 2. support for poll/select As long as the cost of llpoll is bounded per poll()/select() call it will be ok. > 3. support for epoll For this one, I honestly do not know how to proceed. epoll Edge Trigger model is driven by the wakeups events. The wakeups come from frames being delivered by the NIC (for UDP/TCP sockets) If epoll_wait() has to scan the list of epitem to be able to perform the llpoll callback, it will be too slow : We come back to poll() model, with O(N) execution time. Ideally we would have to callback llpoll not from the tcp_poll(), but right before putting current thread in wait mode. > > Also, would you accept a trailing whitespace cleanup patch for > fs/select.c? This has to be submitted to lkml -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
