[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <519C9159.7050807@linux.intel.com>
Date: Wed, 22 May 2013 12:35:21 +0300
From: Eliezer Tamir <eliezer.tamir@...ux.intel.com>
To: Ben Hutchings <bhutchings@...arflare.com>
CC: Alex Rosenbaum <alexr@...lanox.com>,
Dave Miller <davem@...emloft.net>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Don Skidmore <donald.c.skidmore@...el.com>,
e1000-devel@...ts.sourceforge.net,
Willem de Bruijn <willemb@...gle.com>,
Andi Kleen <andi@...stfloor.org>, HPA <hpa@...or.com>,
Eliezer Tamir <eliezer@...ir.org.il>
Subject: Re: [PATCH v3 net-next 0/4] net: low latency Ethernet device polling
On 21/05/2013 21:15, Ben Hutchings wrote:
> On Tue, 2013-05-21 at 15:29 +0300, Eliezer Tamir wrote:
>> 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?
> [...]
>
> I raised this issue back at Plumbers and I thought Jesse said poll() was
> covered. It's likely to be a bit of a toy without that. Also, UDP?
The current patchset covers poll/select for UDP.
Adding poll/select for TCP should be simple, I will try to include it in
the next version.
Epoll should see a gain from the above in the case where all the polled
file descriptors are associated to the same device queue.
A fuller implementation, in the epoll itself would be needed to cover
multiple queues/devices.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists