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
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
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 cre
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 i
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
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 co
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 tha
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 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 co
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
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
11 matches
Mail list logo
