[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ACFB9DF.9080909@nortel.com>
Date: Fri, 09 Oct 2009 16:31:59 -0600
From: "Chris Friesen" <cfriesen@...tel.com>
To: "Brandeburg, Jesse" <jesse.brandeburg@...el.com>
CC: e1000-list <e1000-devel@...ts.sourceforge.net>,
Linux Network Development list <netdev@...r.kernel.org>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"Allan, Bruce W" <bruce.w.allan@...el.com>,
"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
"Ronciak, John" <john.ronciak@...el.com>
Subject: Re: behaviour question for igb on nehalem box
On 10/09/2009 02:22 PM, Brandeburg, Jesse wrote:
> On Fri, 9 Oct 2009, Chris Friesen wrote:
>> I've got some general questions around the expected behaviour of the
>> 82576 igb net device. (On a dual quad-core Nehalem box, if it matters.)
> the hardware you have only supports 8
> queues (rx and tx) and the driver is configured to only set up 4 max.
The datasheet for the 82576 says 16 tx queues and 16 rx queues. Is that
a typo or do we have the economy version?
>> My second question is around how the rx queues are mapped to interrupts.
>> According to /proc/interrupts there appears to be a 1:1 mapping between
>> queues and interrupts. However, I've set up at test with a given amount
>> of traffic coming in to the device (from 4 different IP addresses and 4
>> ports). Under this scenario, "ethtool -S" shows the number of packets
>> increasing for only rx queue 0, but I see the interrupt count going up
>> for two interrupts.
>
> one transmit interrupt and one receive interrupt?
No, two rx interrupts. (Can't remember if the tx interrupt was going up
as well or no...was only looking at rx.)
> RSS will spread the
> receive work out in a flow based way, based on ip/xDP header. Your test
> as described should be using more than one flow (and therefore more than
> one rx queue) unless you got caught out by the default arp_filter
> behavior (check arp -an).
I was surprised as well since it didn't match what I expected. What's
the story around the arp_filter? I just logged onto the test box and
"arp -an" gives:
? (47.135.251.129) at 00:00:5E:00:01:08 [ether] on eth0
but I'm not sure that's worth anything since someone is running a test
and it's currently using all four rx queues and all four rx interrupt
counts are increasing. I'll have to see if they changed anything.
> Hope this helps,
That's great, thanks.
Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists