Many of the questions you asked are covered in our RFC cover letter, but I will touch them briefly
On 21/05/2013 15:06, Alex Rosenbaum wrote: > 1. It seem this patch does not cover epoll/select and such IO muxing APIs? We are thinking about how to implement epoll support as one of the next steps. What benchmarks are you using to test poll/select/epoll? > 2. How is the logic aware of RSS and RFS? > > With TCP sockets, the driver knows the specific ring it need to poll so > this should be mapped and provide the best latency. This code is blissfully oblivious of RFS and RSS, it only assumes that the packets for a socket are likely to continue to come on the same queue. The code is designed to be correct even if you get your data on the wrong queue. (your performance will suffer but no more than that.) > 3. I could not find any reference to multi-thread on single core logic. > This can causes the opposite effect and create contentions and higher > latency’s. Again, the only bad thing that will happen if you misconfigure this is a performance hit, we will not deadlock. -Eliezer ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
