New: High cpu usage when someone sends many ipv6 udp packages

Bugme-new Andrew Morton 3 participants 3 messages Mar 5, 2011 – Mar 7, 2011 2 messages not in the archive

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author

2011-03-05 01:16 UTC #1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 45 lines · On Sat, 5 Mar 2011 01:10:53 GMT [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=30462
           Summary: High cpu usage when someone sends many ipv6 udp
                    packages
           Product: Networking
           Version: 2.5
    Kernel Version: 2.6.38-rc3
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: IPV6
        AssignedTo: [email protected]
        ReportedBy: [email protected]
        Regression: Yes
Hi,
while testing ipv6 performance on my local network I found the following problem.
When sending lots of UDP packages over ipv6 to a machine running kernel 2.6.38-rc3 or later that machines become heavily loaded and X may stop responding for long periods of time for example, sound skips etc. A ksoftirqd and kworker thread each run 100% on my machine.
I'm using this command to trigger this:
iperf -c fe80::21f:d0ff:fe54:1ad4%eth0 -b 1000M -u -V You _don't_ have to setup an iperf server on the reciever.
I have a gigabit network with a WNDR3700 with the new V1.0.7.98 firmware that's "IPv6 ready".
I've used the kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ to narrow down that this happens with 2.6.38-rc3 and later but not with 2.6.38-rc2 and earlier like 2.6.37 and 2.6.35.
The following ipv6 related changes were introduced between -rc2 and -rc3 that I can see. The "Revert 'administrative down' address handling changes." looked big...
ipv6: Always clone offlink routes.
ipv6: Revert 'administrative down' address handling changes.

David Miller

maintainer

2011-03-05 01:21 UTC #2 lore raw

From: Andrew Morton <[email protected]>
Date: Fri, 4 Mar 2011 17:15:06 -0800

Quoted 5 lines

Quoted 5 lines
The following ipv6 related changes were introduced between -rc2 and -rc3 that I can see. The "Revert 'administrative down' address handling changes." looked big...
ipv6: Always clone offlink routes.
ipv6: Revert 'administrative down' address handling changes.

Can we narrow it down to which of those two changes introduced the regression?

We have another issue, still open, which is caused by the first change, so maybe try reverting that one first.

Thanks.

A message that is not in the archive (sent off-list or not yet received): [email protected]

Ernst Sjöstrand

2011-03-07 19:54 UTC #4 lore raw

Hi,

seems like reverting "ipv6: Always clone offlink routes." fixes the issue.

Regards
//Ernst

2011/3/5 Ernst Sjöstrand <[email protected]>:

Quoted 30 lines

I've only used precompiled kernels so far so I don't have stuff set up to compile kernels right now,
probably won't have time to do that this weekend. Not tonight in GMT+1 anyway!
Regards
//Ernst
Quoted 19 lines · David Miller
From: Andrew Morton <[email protected]>
Date: Fri, 4 Mar 2011 17:15:06 -0800
Quoted 7 lines
Quoted 7 lines
The following ipv6 related changes were introduced between -rc2 and -rc3 that I
can see. The "Revert 'administrative down' address handling changes." looked
big...
ipv6: Always clone offlink routes.
ipv6: Revert 'administrative down' address handling changes.
Can we narrow it down to which of those two changes introduced the regression?
We have another issue, still open, which is caused by the first change, so maybe try reverting that one first.
Thanks.