From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eliezer Tamir Subject: Re: [PATCH v3 net-next 0/4] net: low latency Ethernet device polling Date: Tue, 21 May 2013 15:29:24 +0300 Message-ID: <519B68A4.3010406@linux.intel.com> References: <20130520101552.14133.45953.stgit@ladj378.jer.intel.com> <519B632F.7040202@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Dave Miller , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Jesse Brandeburg , Don Skidmore , e1000-devel@lists.sourceforge.net, Willem de Bruijn , Andi Kleen , HPA , Eliezer Tamir To: Alex Rosenbaum Return-path: In-Reply-To: <519B632F.7040202@mellanox.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Many of the questions you asked are covered in our RFC cover letter, bu= t=20 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= =20 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=20 the packets for a socket are likely to continue to come on the same que= ue. The code is designed to be correct even if you get your data on the=20 wrong queue. (your performance will suffer but no more than that.) > 3. I could not find any reference to multi-thread on single core logi= c. > This can causes the opposite effect and create contentions and higher > latency=E2=80=99s. Again, the only bad thing that will happen if you misconfigure this is = a=20 performance hit, we will not deadlock. -Eliezer