[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