On 26/08/2013 09:03, Eliezer Tamir wrote:
> On 26/08/2013 00:30, Amir Vadai wrote:
>> I'm on vacation, will test and have some inputs later this week when I be
>> back.
>>
> Hello Amir,
>
> Ping me when you get back and I will send you my latest so you can
> play with it.
>
Hi Eliezer,
You can
On 26/08/2013 09:03, Eliezer Tamir wrote:
On 26/08/2013 00:30, Amir Vadai wrote:
I'm on vacation, will test and have some inputs later this week when I be
back.
Hello Amir,
Ping me when you get back and I will send you my latest so you can
play with it.
Hi Eliezer,
You can send the
On 26/08/2013 00:30, Amir Vadai wrote:
> I'm on vacation, will test and have some inputs later this week when I be
> back.
>
Hello Amir,
Ping me when you get back and I will send you my latest so you can
play with it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On 26/08/2013 00:30, Amir Vadai wrote:
I'm on vacation, will test and have some inputs later this week when I be
back.
Hello Amir,
Ping me when you get back and I will send you my latest so you can
play with it.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Eliezer Tamir wrote:
> I'm not sure I understand your claim that epoll has a higher latency
> than poll.
Nevermind, I usually live in an EPOLLONESHOT bubble so I use more
epoll_ctl than "normal" epoll apps :x
Anyways, good to know epoll wins over poll. Thanks.
--
To unsubscribe from this list:
On 22/08/2013 23:11, Eric Wong wrote:
> Eliezer Tamir wrote:
>> Performance:
>> using sockperf, Intel X520 NICs,
>> Supermicro 6026TT-BTF systems with E5-2690 Xeon CPUs
>> 100 UDP sockets avg. latency 5.756 (std-dev 0.510)
>> 1k UDP sockets avg. latency 5.780 (std-dev 0.536)
>> 10k UDP sockets
On 22/08/2013 23:14, David Miller wrote:
> From: Eliezer Tamir
> Date: Wed, 21 Aug 2013 13:39:54 +0300
>
>> +SK_LL_STATE_MISS_2, /* data came through napi poll twice in a row */
>
> Please rename this to SK_LL_STATE_MISS_MULTI or something like that.
>
> Thanks.
OK
--
To unsubscribe
On 22/08/2013 23:14, David Miller wrote:
From: Eliezer Tamir eliezer.ta...@linux.intel.com
Date: Wed, 21 Aug 2013 13:39:54 +0300
+SK_LL_STATE_MISS_2, /* data came through napi poll twice in a row */
Please rename this to SK_LL_STATE_MISS_MULTI or something like that.
Thanks.
OK
On 22/08/2013 23:11, Eric Wong wrote:
Eliezer Tamir eliezer.ta...@linux.intel.com wrote:
Performance:
using sockperf, Intel X520 NICs,
Supermicro 6026TT-BTF systems with E5-2690 Xeon CPUs
100 UDP sockets avg. latency 5.756 (std-dev 0.510)
1k UDP sockets avg. latency 5.780 (std-dev 0.536)
Eliezer Tamir eliezer.ta...@linux.intel.com wrote:
I'm not sure I understand your claim that epoll has a higher latency
than poll.
Nevermind, I usually live in an EPOLLONESHOT bubble so I use more
epoll_ctl than normal epoll apps :x
Anyways, good to know epoll wins over poll. Thanks.
--
To
From: Eliezer Tamir
Date: Wed, 21 Aug 2013 13:39:54 +0300
> + SK_LL_STATE_MISS_2, /* data came through napi poll twice in a row */
Please rename this to SK_LL_STATE_MISS_MULTI or something like that.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Eliezer Tamir wrote:
> Performance:
> using sockperf, Intel X520 NICs,
> Supermicro 6026TT-BTF systems with E5-2690 Xeon CPUs
> 100 UDP sockets avg. latency 5.756 (std-dev 0.510)
> 1k UDP sockets avg. latency 5.780 (std-dev 0.536)
> 10k UDP sockets avg. latency 6.269 (std-dev 0.611)
How does
Eliezer Tamir eliezer.ta...@linux.intel.com wrote:
Performance:
using sockperf, Intel X520 NICs,
Supermicro 6026TT-BTF systems with E5-2690 Xeon CPUs
100 UDP sockets avg. latency 5.756 (std-dev 0.510)
1k UDP sockets avg. latency 5.780 (std-dev 0.536)
10k UDP sockets avg. latency 6.269
From: Eliezer Tamir eliezer.ta...@linux.intel.com
Date: Wed, 21 Aug 2013 13:39:54 +0300
+ SK_LL_STATE_MISS_2, /* data came through napi poll twice in a row */
Please rename this to SK_LL_STATE_MISS_MULTI or something like that.
Thanks.
--
To unsubscribe from this list: send the line
On 21/08/2013 16:53, Eric Dumazet wrote:
> On Wed, 2013-08-21 at 13:39 +0300, Eliezer Tamir wrote:
>
>>
>> Instead of remembering the napi_id for all the sockets in an epoll,
>> we only track the first socket we see with any unique napi_id.
>> The rational for this is that while there may be many
On Wed, 2013-08-21 at 13:39 +0300, Eliezer Tamir wrote:
>
> Instead of remembering the napi_id for all the sockets in an epoll,
> we only track the first socket we see with any unique napi_id.
> The rational for this is that while there may be many thousands of
> sockets tracked by a single
Add busy poll support to epoll.
Background:
The persistent nature of epoll allows us to have a long lasting context
that we use to keep track of which device queues we expect traffic
to come on for the sockets monitored by an epoll file.
Design:
We tried to make epoll changes as small as
Add busy poll support to epoll.
Background:
The persistent nature of epoll allows us to have a long lasting context
that we use to keep track of which device queues we expect traffic
to come on for the sockets monitored by an epoll file.
Design:
We tried to make epoll changes as small as
On Wed, 2013-08-21 at 13:39 +0300, Eliezer Tamir wrote:
Instead of remembering the napi_id for all the sockets in an epoll,
we only track the first socket we see with any unique napi_id.
The rational for this is that while there may be many thousands of
sockets tracked by a single epoll, we
On 21/08/2013 16:53, Eric Dumazet wrote:
On Wed, 2013-08-21 at 13:39 +0300, Eliezer Tamir wrote:
Instead of remembering the napi_id for all the sockets in an epoll,
we only track the first socket we see with any unique napi_id.
The rational for this is that while there may be many thousands
20 matches
Mail list logo
