On Fri, 2007-21-09 at 07:43 -0400, jamal wrote:
> one cpu in either bottom/top half has to be slightly loaded and you
> loose the ordering where incoming doesnt match outgoing packet order.
Actually in your case it gets worse because (if i read that code
correctly) you randomly select the CPUs.
On Fri, 2007-21-09 at 17:25 +0800, John Ye wrote:
> David,
>
> Thanks for your reply. I understand it's not worth to do.
>
> I have made it a loadable module to fulfill the function. it mainly for busy
> NAT gateway server with SMP to speed up.
>
John,
It was a little hard to read your code; h
lt;[EMAIL PROTECTED]>
Cc: ; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, September 21, 2007 1:46 AM
Subject: Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently run softirq
network code on SMP
>
> The whole reason th
On Thu, 20 Sep 2007 21:04:16 +0800
"john ye" <[EMAIL PROTECTED]> wrote:
> Bottom Softirq Implementation. John Ye, 2007.08.27
>
> Why this patch:
> Make kernel be able to concurrently execute softirq's net code on SMP
> system.
> Takes full advantages of SMP to handle more packets and greatly rai
The whole reason the queues are per-cpu is so that we do not
have to touch remote processor state nor use locks of any
kind whatsoever.
With multi-queue networking cards becoming more and more
available, which will split up the packet workload in
hardware across all available cpus, there is less
Bottom Softirq Implementation. John Ye, 2007.08.27
Why this patch:
Make kernel be able to concurrently execute softirq's net code on SMP
system.
Takes full advantages of SMP to handle more packets and greatly raises NIC
throughput.
The current kernel's net packet processing logic is:
1) The CPU
