[PATCH] genirq: Set initial default irq affinity to just CPU0
Kumar Gala
galak at kernel.crashing.org
Tue Oct 28 06:43:29 EST 2008
On Oct 27, 2008, at 1:28 PM, David Miller wrote:
> From: "Chris Friesen" <cfriesen at nortel.com>
> Date: Mon, 27 Oct 2008 11:36:21 -0600
>
>> David Miller wrote:
>>> From: Kevin Diggs <kevdig at hypersurf.com>
>>> Date: Sat, 25 Oct 2008 15:53:46 -0700
>>>
>>>> What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this
>>>> thing supposed to be able to spread irq between its cpus?
>>> Networking interrupts should lock onto a single CPU,
>>> unconditionally.
>>> That's the optimal way to handle networking interrupts, especially
>>> with multiqueue chips.
>>
>> What about something like the Cavium Octeon, where we have 16 cores
>> but a single core isn't powerful enough to keep up with a gigE
>> device?
>
> Hello, we either have hardware that does flow seperation and has
> multiple RX queues
> going to multiple MSI-X interrupts or we do flow seperation in
> software (work
> in progress patches were posted for that about a month ago, maybe
> something final
> will land in 2.6.29)
>
> Just moving the interrupt around when not doing flow seperation is as
> suboptimal as you can possibly get. You'll get out of order packet
> processing within the same flow, TCP will retransmit when the
> reordering gets deep enough, and then you're totally screwed
> performance wise.
I haven't been following the netdev patches, but what about HW that
does flow separation w/o multiple interrupts?
We (Freescale) are working on such a device:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?fastpreview=1&code=P4080
- k
More information about the Linuxppc-dev
mailing list