Rusty Russell a écrit :
On Sat, 30 May 2009 12:41:00 am Eric Dumazet wrote:
Rusty Russell a écrit :
DaveM points out that there are advantages to doing it generally (it's
more likely to be on same CPU than after xmit), and I couldn't find
any new starvation issues in simple benchmarking here.
On Thu, 4 Jun 2009 06:32:53 am Eric Dumazet wrote:
Rusty Russell a écrit :
On Sat, 30 May 2009 12:41:00 am Eric Dumazet wrote:
For TCP, I agree your patch is a huge benefit, since its paced by remote
ACKS and window control
I doubt that. There'll be some cache friendliness, but I'm not
From: Rusty Russell ru...@rustcorp.com.au
Date: Thu, 4 Jun 2009 13:24:57 +0930
On Thu, 4 Jun 2009 06:32:53 am Eric Dumazet wrote:
Also, taking a reference on socket for each xmit packet in flight is very
expensive, since it slows down receiver in __udp4_lib_lookup(). Several
cpus are fighting
David Miller a écrit :
From: Rusty Russell ru...@rustcorp.com.au
Date: Thu, 4 Jun 2009 13:24:57 +0930
On Thu, 4 Jun 2009 06:32:53 am Eric Dumazet wrote:
Also, taking a reference on socket for each xmit packet in flight is very
expensive, since it slows down receiver in __udp4_lib_lookup().
From: Eric Dumazet eric.duma...@gmail.com
Date: Thu, 04 Jun 2009 06:54:24 +0200
We also can avoid the sock_put()/sock_hold() pair for each tx packet,
to only touch sk_wmem_alloc (with appropriate atomic_sub_return() in
sock_wfree()
and atomic_dec_test in sk_free
We could initialize
