Eric W. Biederman a écrit :
Eric Dumazet [EMAIL PROTECTED] writes:
Eric W. Biederman a écrit :
Eric Dumazet [EMAIL PROTECTED] writes:
Definitly wanted here. Thank you.
One more refcounting on each socket creation/deletion was expensive.
Really? Have you actually measured that? If the
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 01 Nov 2007 07:58:59 +0100
I agree with you that with current state, this atomic_inc/atomic_dec_and_test
wont come in profiles unless a trivial bench is writen
for(;;){close(socket());}
Just add one packet send and one packet receive in
Currently we have the NET_NS config option, but the only change it
makes is just return ERR_PTR(-EINVAL) inside the cloning call thus
introducing a bunch of a dead code and making the reference counting
unneeded. This is not very good.
So clean the net_namespace.c to fix this.
I have sent a set
On Wed, 31 Oct 2007 22:19:43 +0300
Pavel Emelyanov [EMAIL PROTECTED] wrote:
Currently we have the NET_NS config option, but the only change it
makes is just return ERR_PTR(-EINVAL) inside the cloning call thus
introducing a bunch of a dead code and making the reference counting
unneeded.
Eric Dumazet wrote:
On Wed, 31 Oct 2007 22:19:43 +0300
Pavel Emelyanov [EMAIL PROTECTED] wrote:
Currently we have the NET_NS config option, but the only change it
makes is just return ERR_PTR(-EINVAL) inside the cloning call thus
introducing a bunch of a dead code and making the reference
Pavel Emelyanov wrote:
Currently we have the NET_NS config option, but the only change it
makes is just return ERR_PTR(-EINVAL) inside the cloning call thus
introducing a bunch of a dead code and making the reference counting
unneeded. This is not very good.
So clean the net_namespace.c to fix
Eric Dumazet [EMAIL PROTECTED] writes:
Definitly wanted here. Thank you.
One more refcounting on each socket creation/deletion was expensive.
Really? Have you actually measured that? If the overhead is
measurable and expensive we may want to look at per cpu counters or
something like that.
Eric W. Biederman a écrit :
Eric Dumazet [EMAIL PROTECTED] writes:
Definitly wanted here. Thank you.
One more refcounting on each socket creation/deletion was expensive.
Really? Have you actually measured that? If the overhead is
measurable and expensive we may want to look at per cpu
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 23:40:59 +0100
Eric W. Biederman a écrit :
Eric Dumazet [EMAIL PROTECTED] writes:
Definitly wanted here. Thank you.
One more refcounting on each socket creation/deletion was expensive.
Really? Have you actually
Eric Dumazet [EMAIL PROTECTED] writes:
Eric W. Biederman a écrit :
Eric Dumazet [EMAIL PROTECTED] writes:
Definitly wanted here. Thank you.
One more refcounting on each socket creation/deletion was expensive.
Really? Have you actually measured that? If the overhead is
measurable and
David Miller [EMAIL PROTECTED] writes:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 23:40:59 +0100
Eric W. Biederman a écrit :
Eric Dumazet [EMAIL PROTECTED] writes:
Definitly wanted here. Thank you.
One more refcounting on each socket creation/deletion was
11 matches
Mail list logo