David Miller <[EMAIL PROTECTED]> writes:
>
> Furthermore, prequeue puts the stack input processing work into user
> context, which means that the users will be charged more fairly for
> the work that is done for them.
For more details on this people might want to read the old Lazy Receiver
Proces
From: John Heffner <[EMAIL PROTECTED]>
Date: Thu, 27 Sep 2007 22:26:02 -0400
> I think it really does help in case (4) with old NICs that don't do rx
> checksumming. I'm not sure how many people really care about this
> anymore, but probably some...?
>
> OTOH, it would be nice to get rid of sy
Stephen Hemminger wrote:
On Fri, 28 Sep 2007 00:08:33 +0200
Eric Dumazet <[EMAIL PROTECTED]> wrote:
Hi all
I am sure some of you are going to tell me that prequeue is not
all black :)
Thank you
[RFC] Make TCP prequeue configurable
The TCP prequeue thing is based on old facts, a
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Fri, 28 Sep 2007 00:08:33 +0200
> 1) It adds 48 bytes per 'struct tcp_sock'
> 2) It adds some ugly code in hot paths
> 3) It has a small hit ratio on typical servers using many sockets
> 4) It may have a high hit ratio on UP machines running one process
On Fri, 28 Sep 2007 00:08:33 +0200
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Hi all
>
> I am sure some of you are going to tell me that prequeue is not
> all black :)
>
> Thank you
>
> [RFC] Make TCP prequeue configurable
>
> The TCP prequeue thing is b
Hi all
I am sure some of you are going to tell me that prequeue is not
all black :)
Thank you
[RFC] Make TCP prequeue configurable
The TCP prequeue thing is based on old facts, and has drawbacks.
1) It adds 48 bytes per 'struct tcp_sock'
2) It adds some ugly code in hot paths
3
