headers
Robby Cai | 1 May 2009 01:10
Picon

Re: [PATCH 8/8 V2] MX27ADS: Add CS89x0 support

IIRC, someone in this list recommends to do like the following(for
example), rather than always add new item at the end of the line.

  depends on MACH_IXDP2351 || ARCH_IXDP2X01 || ARCH_PNX010X ||
MACH_MX27ADS || MACH_MX31ADS

And next time if we would like to another new item, saying MACH_MX21ADS,
then the result would be

  depends on MACH_IXDP2351 || ARCH_IXDP2X01 || ARCH_PNX010X ||
MACH_MX21ADS || MACH_MX27ADS || MACH_MX31ADS

Regards,
Robby

On Thu, Apr 30, 2009 at 6:48 PM, Vladimir Barinov <vova.barinov <at> gmail.com>wrote:

> Hello Robby,
>
> Robby Cai wrote:
>
>> Does it make sense if we add keep the new items in the alphabetic/numeric
>> order?
>> Nowadays, seems more and more people are paying attention on this.
>>
>>  What actually do propose to line up in alphabetic/numeric order here?
> AFAIK the alphabetic order is suggested to use in Kconfig files for
> variables.
> Not sure if this valid here. In this patch you can find only added
> dependencies.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Dickinson | 1 May 2009 01:53

Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe)

OK... I've got some more data on it...

I passed a small number of packets through the system and added a ton
of printks to it ;-P

Here's the distribution of values as seen by
skb_rx_queue_recorded()... count on the left, value on the right:
     37 0
     31 1
     31 2
     39 3
     37 4
     31 5
     42 6
     39 7

That's nice and even....  Here's what's getting returned from the
skb_tx_hash().  Again, count on the left, value on the right:
     31 0
     81 1
     37 2
     70 3
     37 4
     31 6

Note that we're entirely missing 5 and 7 and that those interrupts
seem to have gotten munged onto 1 and 3.

I think the voodoo lies within:
    return (u16) (((u64) hash * dev->real_num_tx_queues) >> 32);
(Continue reading)

Permalink | Reply | 19 comments |
headers
senthil kumar | 1 May 2009 04:57

Check out this photo on MyDailyFlog!


Hi!
I would like to invite you to visit MyDailyFlog and see my latest photos. 

Check out: http://www.mydailyflog.com/go/invite_register/senthil_linkedin/36654762&stc=26

Cheers!

senthil kumar

========================================
Got a digital camera?

MyDailyFlog is a personal photo-blogging space where you can easily post
your latest and greatest photos, and share them with your friends and family.

Create your own DailyFlog at www.MyDailyFlog.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unsubscribe: to opt out of further invitations from your friends to see 
their DailyFlogs, please click below:
http://www.mydailyflog.com/go/system/euns=netdev <at> vger.kernel.org&md5=28bc5beff2bc4cc40575a76f5b953909

Please do not reply directly to this email. Questions? Contact us - 
http://www.mydailyflog.com/go/contact_us

MyDailyFlog, Refriendz Ltd. PO BOX 1184, Luton, Bedfordshire, LU1 9AT.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Dickinson | 1 May 2009 06:19

Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe)

Adding a bit more info...

I should add, the other 4 ksoftirqd tasklets _are_ running, they're
just not busy. (In case that wasn't clear...)

Also of note, I rebooted the box (after recompiling with NUMA off).
This time when I push traffic through, only the even-ksoftirqd's were
busy..  I then tweaked some of the ring settings via ethtool and
suddenly the odd-ksoftirqd's became busy (and the even ones went
idle).

Thoughts?  Suggestions?  driver issue?  I'm at 2.6.30-rc3.

(BTW, I'm under the assumption that since only 4 (of 8) ksoftirqd's
are busy that I still have room to make this box go faster).

-A

On Thu, Apr 30, 2009 at 4:53 PM, Andrew Dickinson <andrew <at> whydna.net> wrote:
> OK... I've got some more data on it...
>
> I passed a small number of packets through the system and added a ton
> of printks to it ;-P
>
> Here's the distribution of values as seen by
> skb_rx_queue_recorded()... count on the left, value on the right:
>     37 0
>     31 1
>     31 2
>     39 3
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric Dumazet | 1 May 2009 08:14

Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe)

Andrew Dickinson a écrit :
> OK... I've got some more data on it...
> 
> I passed a small number of packets through the system and added a ton
> of printks to it ;-P
> 
> Here's the distribution of values as seen by
> skb_rx_queue_recorded()... count on the left, value on the right:
>      37 0
>      31 1
>      31 2
>      39 3
>      37 4
>      31 5
>      42 6
>      39 7
> 
> That's nice and even....  Here's what's getting returned from the
> skb_tx_hash().  Again, count on the left, value on the right:
>      31 0
>      81 1
>      37 2
>      70 3
>      37 4
>      31 6
> 
> Note that we're entirely missing 5 and 7 and that those interrupts
> seem to have gotten munged onto 1 and 3.
> 
> I think the voodoo lies within:
(Continue reading)

Permalink | Reply | 15 comments |
headers
Andrew Dickinson | 1 May 2009 08:19

Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe)

On Thu, Apr 30, 2009 at 11:14 PM, Eric Dumazet <dada1 <at> cosmosbay.com> wrote:
> Andrew Dickinson a écrit :
>> OK... I've got some more data on it...
>>
>> I passed a small number of packets through the system and added a ton
>> of printks to it ;-P
>>
>> Here's the distribution of values as seen by
>> skb_rx_queue_recorded()... count on the left, value on the right:
>>      37 0
>>      31 1
>>      31 2
>>      39 3
>>      37 4
>>      31 5
>>      42 6
>>      39 7
>>
>> That's nice and even....  Here's what's getting returned from the
>> skb_tx_hash().  Again, count on the left, value on the right:
>>      31 0
>>      81 1
>>      37 2
>>      70 3
>>      37 4
>>      31 6
>>
>> Note that we're entirely missing 5 and 7 and that those interrupts
>> seem to have gotten munged onto 1 and 3.
>>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Eric Dumazet | 1 May 2009 08:40

Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe)

Andrew Dickinson a écrit :
> On Thu, Apr 30, 2009 at 11:14 PM, Eric Dumazet <dada1 <at> cosmosbay.com> wrote:
>> Andrew Dickinson a écrit :
>>> OK... I've got some more data on it...
>>>
>>> I passed a small number of packets through the system and added a ton
>>> of printks to it ;-P
>>>
>>> Here's the distribution of values as seen by
>>> skb_rx_queue_recorded()... count on the left, value on the right:
>>>      37 0
>>>      31 1
>>>      31 2
>>>      39 3
>>>      37 4
>>>      31 5
>>>      42 6
>>>      39 7
>>>
>>> That's nice and even....  Here's what's getting returned from the
>>> skb_tx_hash().  Again, count on the left, value on the right:
>>>      31 0
>>>      81 1
>>>      37 2
>>>      70 3
>>>      37 4
>>>      31 6
>>>
>>> Note that we're entirely missing 5 and 7 and that those interrupts
>>> seem to have gotten munged onto 1 and 3.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrew Dickinson | 1 May 2009 09:23

Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe)

On Thu, Apr 30, 2009 at 11:40 PM, Eric Dumazet <dada1 <at> cosmosbay.com> wrote:
> Andrew Dickinson a écrit :
>> On Thu, Apr 30, 2009 at 11:14 PM, Eric Dumazet <dada1 <at> cosmosbay.com> wrote:
>>> Andrew Dickinson a écrit :
>>>> OK... I've got some more data on it...
>>>>
>>>> I passed a small number of packets through the system and added a ton
>>>> of printks to it ;-P
>>>>
>>>> Here's the distribution of values as seen by
>>>> skb_rx_queue_recorded()... count on the left, value on the right:
>>>>      37 0
>>>>      31 1
>>>>      31 2
>>>>      39 3
>>>>      37 4
>>>>      31 5
>>>>      42 6
>>>>      39 7
>>>>
>>>> That's nice and even....  Here's what's getting returned from the
>>>> skb_tx_hash().  Again, count on the left, value on the right:
>>>>      31 0
>>>>      81 1
>>>>      37 2
>>>>      70 3
>>>>      37 4
>>>>      31 6
>>>>
>>>> Note that we're entirely missing 5 and 7 and that those interrupts
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Dumazet | 1 May 2009 09:31

Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe)

Andrew Dickinson a écrit :
> On Thu, Apr 30, 2009 at 11:40 PM, Eric Dumazet <dada1 <at> cosmosbay.com> wrote:
>> Andrew Dickinson a écrit :
>>> On Thu, Apr 30, 2009 at 11:14 PM, Eric Dumazet <dada1 <at> cosmosbay.com> wrote:
>>>> Andrew Dickinson a écrit :
>>>>> OK... I've got some more data on it...
>>>>>
>>>>> I passed a small number of packets through the system and added a ton
>>>>> of printks to it ;-P
>>>>>
>>>>> Here's the distribution of values as seen by
>>>>> skb_rx_queue_recorded()... count on the left, value on the right:
>>>>>      37 0
>>>>>      31 1
>>>>>      31 2
>>>>>      39 3
>>>>>      37 4
>>>>>      31 5
>>>>>      42 6
>>>>>      39 7
>>>>>
>>>>> That's nice and even....  Here's what's getting returned from the
>>>>> skb_tx_hash().  Again, count on the left, value on the right:
>>>>>      31 0
>>>>>      81 1
>>>>>      37 2
>>>>>      70 3
>>>>>      37 4
>>>>>      31 6
>>>>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Dumazet | 1 May 2009 09:32

Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe)

Andrew Dickinson a écrit :
> Adding a bit more info...
> 
> I should add, the other 4 ksoftirqd tasklets _are_ running, they're
> just not busy. (In case that wasn't clear...)
> 
> Also of note, I rebooted the box (after recompiling with NUMA off).
> This time when I push traffic through, only the even-ksoftirqd's were
> busy..  I then tweaked some of the ring settings via ethtool and
> suddenly the odd-ksoftirqd's became busy (and the even ones went
> idle).
> 
> Thoughts?  Suggestions?  driver issue?  I'm at 2.6.30-rc3.
> 
> (BTW, I'm under the assumption that since only 4 (of 8) ksoftirqd's
> are busy that I still have room to make this box go faster).

I dont see the point here. ksoftirqd is running only if too much
work has to be done in softirq context. Which should be your case
since you want to saturate cpus with network load.

You could try to change /proc/sys/net/core/netdev_budget if you really
want to trigger ksoftirqd sooner or later, but it wont fundamentally
change routing performance.

If you believe box is loosing frames because cpu are saturated, please
post some oprofile results.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
(Continue reading)

Permalink | Reply | 1 comment |

Gmane