* Kernel Oops
From: RuanZhijie @ 2012-07-07 12:54 UTC (permalink / raw)
To: davem; +Cc: netdev, skinsbursky
Hi, all.
Mr. Stanislav Kinsbursky suggests me send you a report about an oops I encountered in the past few days.
A few days ago, I tested some VMs with NAT enabled under KVM and libvirt, but kernel crashed when I shut down these VMs, though this issue did not occur every time. I did some search and found a webpage(http://www.spinics.net/lists/netdev/msg193846.html) in which Simon reported a similar issue.
The operating system I use is gentoo-amd64 with no-multilib profile, kernel version is 3.4.0, libvirt-0.9.13 with USE flag "qemu virt-network" enabled and qemu-kvm-1.0.1-r1. Here are the steps to reproduce:
1. Let's define that starting a VM with NAT enabled under KVM and libvirt and then shut it down immediately as one operation.
2. Repeat the operation for several times.
I also did 3 tests:
Test 1:
The host machine is with a regular linux 3.4.0 kernel, and the VM had NAT enabled. Kernel crashed after 2, 7 and 13 operations.
Test 2:
The host machine is with a regular linux 3.4.0 kernel, and the VM had no network access. No crash occured after 100 operations.
Test 3:
The host machine is with a linux 3.4.0 kernel, but drivers/net/tun.c was reverted back to just before commit 1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d (https://github.com/torvalds/linux/commit/1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d#drivers/net/tun.c), (or you can use a tun.c from a 3.2.0 kernel, according to Simon's report), and the VM had NAT enabled. No crash occured after 100 operations.
Moreover, I observe that a virtual interface is created to handle network access when a VM with NAT enabled starts, and the virtual interface is removed when the VM is shut down. Crashes usually occur at the time the virtual interface is removed.
Finally, 3 types of kernel crash traces were observed; and thanks to rsyslog, they are all recorded:
Type 1:
2012-07-06T11:44:31.513203+08:00 timemars NetworkManager[1761]: <warn> /sys/devices/virtual/net/vnet0: couldn't determine device driver; ignoring...
2012-07-06T11:44:31.523305+08:00 timemars kernel: device vnet0 entered promiscuous mode
2012-07-06T11:44:31.532555+08:00 timemars kernel: virbr0: topology change detected, propagating
2012-07-06T11:44:31.532591+08:00 timemars kernel: virbr0: port 1(vnet0) entered forwarding state
2012-07-06T11:44:31.532599+08:00 timemars kernel: virbr0: port 1(vnet0) entered forwarding state
2012-07-06T11:44:33.019292+08:00 timemars kernel: virbr0: port 1(vnet0) entered disabled state
2012-07-06T11:44:33.021282+08:00 timemars kernel: virbr0: port 1(vnet0) entered disabled state
2012-07-06T11:44:33.021305+08:00 timemars kernel: device vnet0 left promiscuous mode
2012-07-06T11:44:33.021308+08:00 timemars kernel: virbr0: port 1(vnet0) entered disabled state
2012-07-06T11:44:33.352293+08:00 timemars kernel: BUG: unable to handle kernel paging request at 00001fff813e1b10
2012-07-06T11:44:33.352452+08:00 timemars kernel: IP: [<ffffffff810bcaed>] __pfn_to_section+0x9/0x28
2012-07-06T11:44:33.352509+08:00 timemars kernel: PGD 0
2012-07-06T11:44:33.352562+08:00 timemars kernel: Oops: 0000 [#1] SMP
2012-07-06T11:44:33.352613+08:00 timemars kernel: CPU 1
2012-07-06T11:44:33.352665+08:00 timemars kernel: Modules linked in:
2012-07-06T11:44:33.352716+08:00 timemars kernel:
2012-07-06T11:44:33.352770+08:00 timemars kernel: Pid: 2076, comm: libvirtd Not tainted 3.4.0 #1 Dell Inc. Inspiron 1440 /0K138P
2012-07-06T11:44:33.352826+08:00 timemars kernel: RIP: 0010:[<ffffffff810bcaed>] [<ffffffff810bcaed>] __pfn_to_section+0x9/0x28
2012-07-06T11:44:33.352878+08:00 timemars kernel: RSP: 0018:ffff8800aacc5d40 EFLAGS: 00010246
2012-07-06T11:44:33.352931+08:00 timemars kernel: RAX: 0000000000000000 RBX: ffffe780281e6600 RCX: fffffe780281e660
2012-07-06T11:44:33.352983+08:00 timemars kernel: RDX: 0000000000003434 RSI: 0000000000000207 RDI: 000003fffff9e00a
2012-07-06T11:44:33.353035+08:00 timemars kernel: RBP: ffff8800a0799820 R08: dead000000100100 R09: dead000000200200
2012-07-06T11:44:33.353053+08:00 timemars kernel: R10: ffff88011fd10b40 R11: ffff88011fd10b40 R12: ffff8800a0799800
2012-07-06T11:44:33.353061+08:00 timemars kernel: R13: ffff8800948ef800 R14: 0000000000000000 R15: ffff8800948ef000
2012-07-06T11:44:33.353094+08:00 timemars kernel: FS: 00007ff98fdf1700(0000) GS:ffff88011fd00000(0000) knlGS:0000000000000000
2012-07-06T11:44:33.353103+08:00 timemars kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
2012-07-06T11:44:33.353110+08:00 timemars kernel: CR2: 00001fff813e1b10 CR3: 00000000aaceb000 CR4: 00000000000407e0
2012-07-06T11:44:33.353117+08:00 timemars kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
2012-07-06T11:44:33.353143+08:00 timemars kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
2012-07-06T11:44:33.353153+08:00 timemars kernel: Process libvirtd (pid: 2076, threadinfo ffff8800aacc4000, task ffff8800aeaff200)
2012-07-06T11:44:33.353160+08:00 timemars kernel: Stack:
2012-07-06T11:44:33.353169+08:00 timemars kernel: ffffffff810bcb2b ffff8800a0799820 ffffffff810bc004 ffff880118cfc920
2012-07-06T11:44:33.353176+08:00 timemars kernel: ffff8800a2368f00 0000000200005058 0000000000000002 ffff880104aa8618
2012-07-06T11:44:33.353183+08:00 timemars kernel: ffffffff81608dc0 0000000000000000 0000000000000000 0000000200000005
2012-07-06T11:44:33.353190+08:00 timemars kernel: Call Trace:
2012-07-06T11:44:33.353198+08:00 timemars kernel: [<ffffffff810bcb2b>] ? lookup_page_cgroup+0x1f/0x28
2012-07-06T11:44:33.353206+08:00 timemars kernel: [<ffffffff810bc004>] ? mem_cgroup_force_empty+0x1c1/0x496
2012-07-06T11:44:33.353213+08:00 timemars kernel: [<ffffffff810d318d>] ? mntput_no_expire+0x1f/0xf4
2012-07-06T11:44:33.353222+08:00 timemars kernel: [<ffffffff8105f2ef>] ? should_resched+0x5/0x23
2012-07-06T11:44:33.353230+08:00 timemars kernel: [<ffffffff81079d92>] ? cgroup_rmdir+0x9d/0x39c
2012-07-06T11:44:33.353237+08:00 timemars kernel: [<ffffffff8105a4e8>] ? add_wait_queue+0x3c/0x3c
2012-07-06T11:44:33.353244+08:00 timemars kernel: [<ffffffff8105f2ef>] ? should_resched+0x5/0x23
2012-07-06T11:44:33.353250+08:00 timemars kernel: [<ffffffff810c859e>] ? vfs_rmdir+0x67/0xab
2012-07-06T11:44:33.353275+08:00 timemars kernel: [<ffffffff810c8f4b>] ? do_rmdir+0xad/0x101
2012-07-06T11:44:33.353285+08:00 timemars kernel: [<ffffffff810d318d>] ? mntput_no_expire+0x1f/0xf4
2012-07-06T11:44:33.353293+08:00 timemars kernel: [<ffffffff810bd095>] ? filp_close+0x57/0x5f
2012-07-06T11:44:33.353321+08:00 timemars kernel: [<ffffffff813eaf62>] ? system_call_fastpath+0x16/0x1b
2012-07-06T11:44:33.353333+08:00 timemars kernel: Code: 8b bd 28 01 00 00 e8 fc c8 ff ff eb 03 45 31 ff 48 83 c4 68 4c 89 f8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 89 f9 48 c1 ef 16 31 c0 <48> 8b 14 fd c0 1a 6f 81 48 c1 e9 0f 48 85 d2 74 0d 48 89 c8 83
2012-07-06T11:44:33.353341+08:00 timemars kernel: RIP [<ffffffff810bcaed>] __pfn_to_section+0x9/0x28
2012-07-06T11:44:33.353366+08:00 timemars kernel: RSP <ffff8800aacc5d40>
2012-07-06T11:44:33.353374+08:00 timemars kernel: CR2: 00001fff813e1b10
2012-07-06T11:44:33.353398+08:00 timemars kernel: ---[ end trace 239af6a79d1fdbe3 ]---
Type 2:
2012-07-06T12:46:13.772228+08:00 timemars NetworkManager[1684]: <warn> /sys/devices/virtual/net/vnet0: couldn't determine device driver; ignoring...
2012-07-06T12:46:13.782523+08:00 timemars kernel: device vnet0 entered promiscuous mode
2012-07-06T12:46:13.792507+08:00 timemars kernel: virbr0: topology change detected, propagating
2012-07-06T12:46:13.792539+08:00 timemars kernel: virbr0: port 1(vnet0) entered forwarding state
2012-07-06T12:46:13.792543+08:00 timemars kernel: virbr0: port 1(vnet0) entered forwarding state
2012-07-06T12:46:15.097601+08:00 timemars kernel: virbr0: port 1(vnet0) entered disabled state
2012-07-06T12:46:15.097628+08:00 timemars kernel: device vnet0 left promiscuous mode
2012-07-06T12:46:15.097632+08:00 timemars kernel: virbr0: port 1(vnet0) entered disabled state
2012-07-06T12:46:15.112429+08:00 timemars kernel: BUG: unable to handle kernel paging request at ffffff816d9f715f
2012-07-06T12:46:15.112456+08:00 timemars kernel: IP: [<ffffffff810a9bc6>] filp_close+0x30/0x5f
2012-07-06T12:46:15.112459+08:00 timemars kernel: PGD 15a1067 PUD 0
2012-07-06T12:46:15.112477+08:00 timemars kernel: Oops: 0000 [#1] SMP
2012-07-06T12:46:15.112480+08:00 timemars kernel: CPU 0
2012-07-06T12:46:15.112483+08:00 timemars kernel: Modules linked in:
2012-07-06T12:46:15.112486+08:00 timemars kernel:
2012-07-06T12:46:15.112489+08:00 timemars kernel: Pid: 2868, comm: qemu-system-x86 Not tainted 3.4.0 #1 Dell Inc. Inspiron 1440 /0K138P
2012-07-06T12:46:15.112494+08:00 timemars kernel: RIP: 0010:[<ffffffff810a9bc6>] [<ffffffff810a9bc6>] filp_close+0x30/0x5f
2012-07-06T12:46:15.112497+08:00 timemars kernel: RSP: 0018:ffff8800a676bcc8 EFLAGS: 00010286
2012-07-06T12:46:15.112500+08:00 timemars kernel: RAX: ffffff816d9f70ff RBX: ffff8800a53bafff RCX: 000000000000000f
2012-07-06T12:46:15.112503+08:00 timemars kernel: RDX: 0000000000000000 RSI: ffff88011b26d080 RDI: ffff8800a53bafff
2012-07-06T12:46:15.112506+08:00 timemars kernel: RBP: ffff88011b26d080 R08: ffff8800a40de000 R09: ffff88009bd0f800
2012-07-06T12:46:15.112510+08:00 timemars kernel: R10: ffffffff81130d8d R11: ffffffff812f0aa6 R12: 0000000000000000
2012-07-06T12:46:15.112513+08:00 timemars kernel: R13: 0000000000000001 R14: ffff88009bcc3c80 R15: 0000000000000004
2012-07-06T12:46:15.112516+08:00 timemars kernel: FS: 00007fa1d2654700(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000
2012-07-06T12:46:15.112519+08:00 timemars kernel: CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
2012-07-06T12:46:15.112522+08:00 timemars kernel: CR2: ffffff816d9f715f CR3: 000000000159f000 CR4: 00000000000427e0
2012-07-06T12:46:15.112525+08:00 timemars kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
2012-07-06T12:46:15.112528+08:00 timemars kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
2012-07-06T12:46:15.112532+08:00 timemars kernel: Process qemu-system-x86 (pid: 2868, threadinfo ffff8800a676a000, task ffff88009bc9cec0)
2012-07-06T12:46:15.112542+08:00 timemars kernel: Stack:
2012-07-06T12:46:15.112546+08:00 timemars kernel: ffff88011b26d080 0000000000000000 00000000000fdfbf ffffffff81048e0d
2012-07-06T12:46:15.112548+08:00 timemars kernel: ffffffff81130d8d ffff88009bc9cec0 0000000000000000 00007ffffffff000
2012-07-06T12:46:15.112551+08:00 timemars kernel: ffff88009bc9cec0 ffff88009bc9cec0 0000000000000001 ffffffff810490e7
2012-07-06T12:46:15.112554+08:00 timemars kernel: Call Trace:
2012-07-06T12:46:15.112557+08:00 timemars kernel: [<ffffffff81048e0d>] ? put_files_struct+0x60/0xb9
2012-07-06T12:46:15.112575+08:00 timemars kernel: [<ffffffff81130d8d>] ? exit_sem+0x1e8/0x1f7
2012-07-06T12:46:15.112579+08:00 timemars kernel: [<ffffffff810490e7>] ? do_exit+0x204/0x6df
2012-07-06T12:46:15.112582+08:00 timemars kernel: [<ffffffff8104983e>] ? do_group_exit+0x70/0x9a
2012-07-06T12:46:15.112585+08:00 timemars kernel: [<ffffffff810516ff>] ? get_signal_to_deliver+0x40d/0x42f
2012-07-06T12:46:15.112588+08:00 timemars kernel: [<ffffffff81027796>] ? do_signal+0x38/0x431
2012-07-06T12:46:15.112591+08:00 timemars kernel: [<ffffffff81051a9f>] ? copy_siginfo_to_user+0x5c/0x1bb
2012-07-06T12:46:15.112594+08:00 timemars kernel: [<ffffffff810715a5>] ? sys_futex+0x138/0x147
2012-07-06T12:46:15.112597+08:00 timemars kernel: [<ffffffff81027bc5>] ? do_notify_resume+0x25/0x50
2012-07-06T12:46:15.112600+08:00 timemars kernel: [<ffffffff8105f152>] ? should_resched+0x5/0x23
2012-07-06T12:46:15.112603+08:00 timemars kernel: [<ffffffff813d511b>] ? _cond_resched+0x6/0x1a
2012-07-06T12:46:15.112606+08:00 timemars kernel: [<ffffffff813d6628>] ? int_signal+0x12/0x17
2012-07-06T12:46:15.112610+08:00 timemars kernel: Code: f5 53 48 89 fb 48 8b 47 30 48 85 c0 75 11 48 c7 c7 ec 6d 50 81 45 31 e4 e8 1f 67 32 00 eb 33 48 8b 47 20 45 31 e4 48 85 c0 74 0e <48> 8b 40 60 48 85 c0 74 05 ff d0 41 89 c4 f6 43 3d 40 75 0b 48
2012-07-06T12:46:15.112613+08:00 timemars kernel: RIP [<ffffffff810a9bc6>] filp_close+0x30/0x5f
2012-07-06T12:46:15.112616+08:00 timemars kernel: RSP <ffff8800a676bcc8>
2012-07-06T12:46:15.112624+08:00 timemars kernel: CR2: ffffff816d9f715f
2012-07-06T12:46:15.179496+08:00 timemars kernel: ---[ end trace deec135ba51c758d ]---
2012-07-06T12:46:15.179516+08:00 timemars kernel: Fixing recursive fault but reboot is needed!
Type 3:
2012-07-07T19:51:52.532199+08:00 timemars NetworkManager[1778]: <warn> /sys/devices/virtual/net/vnet0: couldn't determine device driver; ignoring...
2012-07-07T19:51:52.539805+08:00 timemars kernel: device vnet0 entered promiscuous mode
2012-07-07T19:51:52.550668+08:00 timemars kernel: virbr0: topology change detected, propagating
2012-07-07T19:51:52.550704+08:00 timemars kernel: virbr0: port 1(vnet0) entered forwarding state
2012-07-07T19:51:52.550713+08:00 timemars kernel: virbr0: port 1(vnet0) entered forwarding state
2012-07-07T19:51:54.245653+08:00 timemars kernel: virbr0: port 1(vnet0) entered disabled state
2012-07-07T19:51:54.245680+08:00 timemars kernel: device vnet0 left promiscuous mode
2012-07-07T19:51:54.245684+08:00 timemars kernel: virbr0: port 1(vnet0) entered disabled state
2012-07-07T19:51:54.252041+08:00 timemars kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
2012-07-07T19:51:54.252071+08:00 timemars kernel: IP: [<ffffffff810d04f2>] iput+0x3e/0x191
2012-07-07T19:51:54.252074+08:00 timemars kernel: PGD 0
2012-07-07T19:51:54.252078+08:00 timemars kernel: Oops: 0000 [#1] SMP
2012-07-07T19:51:54.252080+08:00 timemars kernel: CPU 1
2012-07-07T19:51:54.252085+08:00 timemars kernel: Modules linked in:
2012-07-07T19:51:54.252088+08:00 timemars kernel:
2012-07-07T19:51:54.252091+08:00 timemars kernel: Pid: 2608, comm: qemu-system-x86 Not tainted 3.4.0 #1 Dell Inc. Inspiron 1440 /0K138P
2012-07-07T19:51:54.252095+08:00 timemars kernel: RIP: 0010:[<ffffffff810d04f2>] [<ffffffff810d04f2>] iput+0x3e/0x191
2012-07-07T19:51:54.252099+08:00 timemars kernel: RSP: 0018:ffff880102fede58 EFLAGS: 00010246
2012-07-07T19:51:54.252102+08:00 timemars kernel: RAX: 0000000000000001 RBX: ffff8800ac78ef20 RCX: ffff88011fd00000
2012-07-07T19:51:54.252105+08:00 timemars kernel: RDX: ffff88011fd00000 RSI: ffff8800ac78ef88 RDI: ffff8800ac78ef88
2012-07-07T19:51:54.252108+08:00 timemars kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8160c4a0
2012-07-07T19:51:54.252111+08:00 timemars kernel: R10: dead000000200200 R11: ffff880118eb3400 R12: 00000000fffcfaf8
2012-07-07T19:51:54.252115+08:00 timemars kernel: R13: 0000000000000000 R14: ffff880102fede88 R15: 00000000fffcfaf8
2012-07-07T19:51:54.252118+08:00 timemars kernel: FS: 00007f51766358c0(0000) GS:ffff88011fd00000(0000) knlGS:0000000000000000
2012-07-07T19:51:54.252121+08:00 timemars kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
2012-07-07T19:51:54.252124+08:00 timemars kernel: CR2: 0000000000000030 CR3: 0000000118d41000 CR4: 00000000000427f0
2012-07-07T19:51:54.252139+08:00 timemars kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
2012-07-07T19:51:54.252142+08:00 timemars kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
2012-07-07T19:51:54.252145+08:00 timemars kernel: Process qemu-system-x86 (pid: 2608, threadinfo ffff880102fec000, task ffff8800a5f3da00)
2012-07-07T19:51:54.252148+08:00 timemars kernel: Stack:
2012-07-07T19:51:54.252151+08:00 timemars kernel: ffff880118eb3400 ffff8800ac78e800 00000000fffcfaf8 ffffffff81307563
2012-07-07T19:51:54.252163+08:00 timemars kernel: ffff8800ac78ec00 ffffffff813169ef ffff880102fede88 ffff880102fede88
2012-07-07T19:51:54.252166+08:00 timemars kernel: dead000000100100 ffff8801174bc2a0 ffff8800ac78e800 ffff8800ac78ee80
2012-07-07T19:51:54.252169+08:00 timemars kernel: Call Trace:
2012-07-07T19:51:54.252172+08:00 timemars kernel: [<ffffffff81307563>] ? sk_release_kernel+0x28/0x47
2012-07-07T19:51:54.252175+08:00 timemars kernel: [<ffffffff813169ef>] ? netdev_run_todo+0x1c9/0x1f3
2012-07-07T19:51:54.252178+08:00 timemars kernel: [<ffffffff81244bb3>] ? tun_chr_close+0x4c/0x99
2012-07-07T19:51:54.252180+08:00 timemars kernel: [<ffffffff810bf948>] ? fput+0xf9/0x1ea
2012-07-07T19:51:54.252192+08:00 timemars kernel: [<ffffffff810bd095>] ? filp_close+0x57/0x5f
2012-07-07T19:51:54.252195+08:00 timemars kernel: [<ffffffff810bd111>] ? sys_close+0x74/0xb1
2012-07-07T19:51:54.252198+08:00 timemars kernel: [<ffffffff813eaf62>] ? system_call_fastpath+0x16/0x1b
2012-07-07T19:51:54.252210+08:00 timemars kernel: Code: 00 00 00 40 74 02 0f 0b 48 8d 77 68 48 8d bf 00 01 00 00 e8 29 ef 08 00 85 c0 0f 84 59 01 00 00 48 8b 6b 18 f6 83 80 00 00 00 08 <4c> 8b 65 30 74 11 be 61 05 00 00 48 c7 c7 45 27 52 81 e8 da 5a
2012-07-07T19:51:54.252214+08:00 timemars kernel: RIP [<ffffffff810d04f2>] iput+0x3e/0x191
2012-07-07T19:51:54.252217+08:00 timemars kernel: RSP <ffff880102fede58>
2012-07-07T19:51:54.252219+08:00 timemars kernel: CR2: 0000000000000030
2012-07-07T19:51:54.298648+08:00 timemars kernel: ---[ end trace 23837b1c67685f78 ]---
Best wishes,
Zhijie
^ permalink raw reply
* Re: [PATCH] smsc95xx: support ethtool get_regs
From: Émeric Vigier @ 2012-07-07 13:58 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Steve Glendinning, steve glendinning, netdev, Nancy Lin
In-Reply-To: <1341620651.2923.49.camel@bwh-desktop.uk.solarflarecom.com>
----- Mail original -----
> On Fri, 2012-07-06 at 14:15 -0400, Émeric Vigier wrote:
> > From: Emeric Vigier <emeric.vigier@savoirfairelinux.com>
> >
> > Inspired by implementation in smsc911x.c and smsc9420.c
> > Tested on ARM/pandaboard rev A3
> >
> > Signed-off-by: Emeric Vigier <emeric.vigier@savoirfairelinux.com>
> > ---
> > drivers/net/usb/smsc95xx.c | 37
> > +++++++++++++++++++++++++++++++++++++
> > 1 files changed, 37 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/usb/smsc95xx.c
> > b/drivers/net/usb/smsc95xx.c
> > index b1112e7..bce14f6 100644
> > --- a/drivers/net/usb/smsc95xx.c
> > +++ b/drivers/net/usb/smsc95xx.c
> > @@ -578,6 +578,41 @@ static int smsc95xx_ethtool_set_eeprom(struct
> > net_device *netdev,
> > return smsc95xx_write_eeprom(dev, ee->offset, ee->len, data);
> > }
> >
> > +
> > +static int smsc95xx_ethtool_getregslen(struct net_device *dev)
> > +{
> > + /* all smsc95xx registers plus all phy registers */
> > + return COE_CR - ID_REV + 1 + 32 * sizeof(u32);
> > +}
> > +
> > +static void
> > +smsc95xx_ethtool_getregs(struct net_device *netdev, struct
> > ethtool_regs *regs,
> > + void *buf)
> > +{
> > + struct usbnet *dev = netdev_priv(netdev);
> > + unsigned int i, j = 0, retval;
> > + u32 *data = buf;
> > +
> > + netif_dbg(dev, hw, dev->net, "ethtool_getregs\n");
> > +
> > + retval = smsc95xx_read_reg(dev, ID_REV, ®s->version);
> > + if (retval < 0) {
> > + netdev_warn(dev->net, "REGS: cannot read ID_REV\n");
> > + return;
> > + }
> > +
> > + for (i = 0; i <= COE_CR; i += (sizeof(u32))) {
> > + retval = smsc95xx_read_reg(dev, i, &data[j++]);
> > + if (retval < 0) {
> > + netdev_warn(dev->net, "REGS: cannot read reg[%x]\n", i);
> > + return;
> > + }
> > + }
>
> Why does this start with i = 0 whereas the calculation of the length
> uses ID_REV as the starting point? Maybe ID_REV == 0, but you should
> be
> consistent in whether you use the name or literal number.
You are right. I will broadcast ID_REV usage.
>
> > + for (i = 0; i <= PHY_SPECIAL; i++)
> > + data[j++] = smsc95xx_mdio_read(netdev, dev->mii.phy_id, i);
> > +}
>
> Again, why use PHY_SPECIAL (+ 1) here as opposed to 32 in the
> calculation of the length?
32 was ok, but I hesitated between defining a SMSC95XX_PHY_END or using the last defined register.
Are 32 register-PHY generic to most devices? I mean could 32 be use widely?
>
> Ben.
>
> > static const struct ethtool_ops smsc95xx_ethtool_ops = {
> > .get_link = usbnet_get_link,
> > .nway_reset = usbnet_nway_reset,
> > @@ -589,6 +624,8 @@ static const struct ethtool_ops
> > smsc95xx_ethtool_ops = {
> > .get_eeprom_len = smsc95xx_ethtool_get_eeprom_len,
> > .get_eeprom = smsc95xx_ethtool_get_eeprom,
> > .set_eeprom = smsc95xx_ethtool_set_eeprom,
> > + .get_regs_len = smsc95xx_ethtool_getregslen,
> > + .get_regs = smsc95xx_ethtool_getregs,
> > };
> >
> > static int smsc95xx_ioctl(struct net_device *netdev, struct ifreq
> > *rq, int cmd)
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
--
Emeric
^ permalink raw reply
* Re: [PATCH] smsc95xx: support ethtool get_regs
From: Émeric Vigier @ 2012-07-07 14:13 UTC (permalink / raw)
To: Francois Romieu; +Cc: Steve Glendinning, netdev, Nancy Lin
In-Reply-To: <20120706221102.GA14276@electric-eye.fr.zoreil.com>
----- Mail original -----
> Émeric Vigier <emeric.vigier@savoirfairelinux.com> :
> [...]
> > Yes, there are 16 bits wide according to smsc95xx.h.
> > But other smsc drivers define 32bit wide PHY regs. I made myself
> > believe
> > that smsc would use the same PHY for each ethernet chip.
>
> SMSC people would surely answer before I find the relevant datasheet.
>
> Anyway the PHY registers are accessed indirectly through the
> MII_{ADDR, DATA}
> registers and MII_DATA r/w mask is limited to the lower 16 bits.
>
> > So would something like s/32 * sizeof(u32)/PHY_SPECIAL *
> > sizeof(u16)/ solve the issue here?
>
> You would have to pack data[] as well. Or use u16 *.
I will check this out next week.
>
> > Concerning the ioctl, I found ethtool much easier to use. And I
> > believe
> > smsc9514 is a very popular chipset, so this could help others
> > debugging it.
>
> # mii-tool -vv e1000
> Using SIOCGMIIPHY=0x8947
> e1000: no autonegotiation, 10baseT-HD, link ok
> registers for MII PHY 0:
> 1140 796d 0141 0c30 0de1 0021 0004 0000
> 0000 0200 0000 0000 0000 0000 0000 3000
> 0000 0000 0000 0000 0174 0000 0000 0000
> 4100 0000 000d 000f 0000 0000 0000 0000
> product info: vendor 00:50:43, model 3 rev 0
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
> 10baseT-HD
> advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
> 10baseT-HD flow-control
> link partner: 10baseT-HD
>
> It is not that bad for the first 32 PHY registers.
I didn't know about mii-tool. Thanks.
>
> [...]
> > Do you mean LTT? I am not familiar with it, I should have a look.
>
> Documentation/trace/ftrace.txt
ok
>
> [...]
> > I should change that in previous "for" loop as well I suppose?
>
> You may.
Thanks for your patience.
>
> --
> Ueimor
>
--
Emeric
^ permalink raw reply
* Re: pre-fetching skb for delayed send
From: Benjamin LaHaise @ 2012-07-07 14:18 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4FF7B7E1.4000602@candelatech.com>
On Fri, Jul 06, 2012 at 09:15:29PM -0700, Ben Greear wrote:
> Well, to start with..I at least know the next skb to transmit,
> so I figured I'd prefetch it before starting tx of the current
> skb.
Prefetching data you're just about to immediately access doesn't actually
help improve performance -- it's better to just access the data. Prefetching
subsequent skbs should be of more benefit.
> My question is more basic though: Given an skb, how do you prefetch
> it...do you just prefetch the skb pointer, or do you need to dig into
> the guts of the skb?
See prefetch.h for details. Just pass the pointer to the cacheline you want
to trigger prefetch on to prefetch() or prefetchw(), or use prefetch_range()
(probably useful for skbs given that they're larger than one cacheline).
For an skb, you may have to prefetch the frag list as well.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Kedves Győztes
From: John Herbert @ 2012-07-07 14:49 UTC (permalink / raw)
Kedves Győztes
E-mail címed szerencsésen választotta az ENSZ kártérítésre jogosult / kedvezményezett összege $ 1,000,000,00 és a bank Bankkártya már letétbe helyezett Ezex Courier Express szállít nekik, hogy az Ön számára. Ön javasoljuk, hogy forduljon a futár tiszt nekik szállítani a Bank Bankkártya Önnek az alábbi information.When kapcsolatba vele, kérjük, küldje el neki a partner címe és azonosítószáma, hogy tudja teljesíteni a Bank Bankkártya Önnek
kapcsolatot a futár tiszt az alábbi információkat
Kapcsolattartó személy: Harry Richard
E-mail: harry.richard@diplomats.com
Kérjük kérek
Üdvözlettel
Mr.John Herbert
^ permalink raw reply
* Re: [iproute2] display vlan configuration
From: Fabien C. @ 2012-07-07 16:03 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev
In-Reply-To: <4FF62146.9070702@intel.com>
Le 06/07/2012 01:20, John Fastabend a écrit :
> Here you need to show the details,
> #ip -d link show dev eth2.333
Thanks for your answer!
The man page doesn't document this option (-d), but "ip help" does, so I guess I didn't search enough.
Fabien
^ permalink raw reply
* [PATCH] net: fix non-ANSI function declaration warning
From: Emil Goode @ 2012-07-07 18:47 UTC (permalink / raw)
To: edumazet, mirq-linux, jpirko, therbert
Cc: netdev, kernel-janitors, Emil Goode
Sparse is warning about non-ANSI function declaration.
Add void to the parameterless function.
net/core/dev.c:1804:38: warning:
non-ANSI function declaration of function
'netif_get_num_default_rss_queues'
Signed-off-by: Emil Goode <emilgoode@gmail.com>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 07c1251..fc6fbce 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1801,7 +1801,7 @@ EXPORT_SYMBOL(netif_set_real_num_rx_queues);
* This routine should set an upper limit on the number of RSS queues
* used by default by multiqueue devices.
*/
-int netif_get_num_default_rss_queues()
+int netif_get_num_default_rss_queues(void)
{
return min_t(int, DEFAULT_MAX_NUM_RSS_QUEUES, num_online_cpus());
}
--
1.7.10.4
^ permalink raw reply related
* su buzón de correo
From: Administrador del sistema @ 2012-07-07 18:50 UTC (permalink / raw)
ADVERTENCIA;
Su buzón ha superado el límite de almacenamiento es de 5 GB, según lo definido por el administrador, que se está ejecutando en 10.9GB, no podrás ser capaz de enviar o recibir nuevos mensajes hasta que vuelva a validar su buzón de correo Correo. Para validar su buzón de correo, enviar la siguiente información a continuación:
nombre:
Nombre de Usuario:
contraseña:
Confirmar contraseña:
E-mail:
Si usted no puede validar su buzón de correo, el correo será habilitado!
muchas gracias
Administrador del sistema
^ permalink raw reply
* Re: [PATCH] smsc95xx: support ethtool get_regs
From: Ben Hutchings @ 2012-07-07 19:55 UTC (permalink / raw)
To: Émeric Vigier
Cc: Steve Glendinning, steve glendinning, netdev, Nancy Lin
In-Reply-To: <203906907.2074.1341669484945.JavaMail.root@mail.savoirfairelinux.com>
On Sat, 2012-07-07 at 09:58 -0400, Émeric Vigier wrote:
[...]
> > > + for (i = 0; i <= PHY_SPECIAL; i++)
> > > + data[j++] = smsc95xx_mdio_read(netdev, dev->mii.phy_id, i);
> > > +}
> >
> > Again, why use PHY_SPECIAL (+ 1) here as opposed to 32 in the
> > calculation of the length?
>
> 32 was ok, but I hesitated between defining a SMSC95XX_PHY_END or using the last defined register.
> Are 32 register-PHY generic to most devices? I mean could 32 be use widely?
Yes, the address space for the original MDIO protocol ('clause 22')
allows for 32 registers. Perhaps that number should be named in
<linux/mii.h>.
As another reviewer commented, though, MDIO PHY registers should be
accessible with SIOCGMIIREG and mii-tool so it's not really necessary to
duplicate them here.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: fix non-ANSI function declaration warning
From: Ben Hutchings @ 2012-07-07 19:57 UTC (permalink / raw)
To: Emil Goode
Cc: edumazet, mirq-linux, jpirko, therbert, netdev, kernel-janitors
In-Reply-To: <1341686871-21822-1-git-send-email-emilgoode@gmail.com>
On Sat, 2012-07-07 at 20:47 +0200, Emil Goode wrote:
> Sparse is warning about non-ANSI function declaration.
> Add void to the parameterless function.
>
> net/core/dev.c:1804:38: warning:
> non-ANSI function declaration of function
> 'netif_get_num_default_rss_queues'
I also posted a patch for this (and another instance I found).
Ben.
> Signed-off-by: Emil Goode <emilgoode@gmail.com>
> ---
> net/core/dev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 07c1251..fc6fbce 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1801,7 +1801,7 @@ EXPORT_SYMBOL(netif_set_real_num_rx_queues);
> * This routine should set an upper limit on the number of RSS queues
> * used by default by multiqueue devices.
> */
> -int netif_get_num_default_rss_queues()
> +int netif_get_num_default_rss_queues(void)
> {
> return min_t(int, DEFAULT_MAX_NUM_RSS_QUEUES, num_online_cpus());
> }
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: fix non-ANSI function declaration warning
From: David Miller @ 2012-07-07 23:12 UTC (permalink / raw)
To: bhutchings
Cc: emilgoode, edumazet, mirq-linux, jpirko, therbert, netdev,
kernel-janitors
In-Reply-To: <1341691049.25597.169.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Sat, 7 Jul 2012 20:57:29 +0100
> On Sat, 2012-07-07 at 20:47 +0200, Emil Goode wrote:
>> Sparse is warning about non-ANSI function declaration.
>> Add void to the parameterless function.
>>
>> net/core/dev.c:1804:38: warning:
>> non-ANSI function declaration of function
>> 'netif_get_num_default_rss_queues'
>
> I also posted a patch for this (and another instance I found).
But you were asked to fix up the comment formatting in on of those
patches so you need to fix that up and resubmit the entire set.
^ permalink raw reply
* Re: [PATCH next-next] ppp: change default for incoming protocol filter to NPMODE_DROP
From: David Miller @ 2012-07-07 23:15 UTC (permalink / raw)
To: bcrl; +Cc: netdev, linux-ppp
In-Reply-To: <20120706172800.GC19462@kvack.org>
From: Benjamin LaHaise <bcrl@kvack.org>
Date: Fri, 6 Jul 2012 13:28:00 -0400
> How about the following addition instead to provide a list of
> protocols to disable?
The userspace programs must accomodate all existing kernels, so
the addition of this feature is rather pointless.
^ permalink raw reply
* Re: [PATCH] r6040: remove duplicate call to the pci_set_drvdata
From: David Miller @ 2012-07-07 23:16 UTC (permalink / raw)
To: devendra.aaru; +Cc: florian, netdev
In-Reply-To: <1341641255-26429-1-git-send-email-devendra.aaru@gmail.com>
From: Devendra Naga <devendra.aaru@gmail.com>
Date: Sat, 7 Jul 2012 11:37:35 +0530
> pci_set_drvdata is called twice at the remove path of driver,
> call it once.
>
> Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 00/18] netfilter updates for net-next (upcoming 3.6), batch 5
From: David Miller @ 2012-07-07 23:23 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1341573428-3204-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Fri, 6 Jul 2012 13:16:50 +0200
> The following patchset includes Netfilter updates for your net-next tree,
> more specifically:
>
> * Updates to clean-up the sysctl namespace support for nf_conntrack
> from Gao Feng and a couple of patches from myself. After these, we
> can prepare follow-up patches to reduce ifdef pollution regarding
> sysctl support in nf_conntrack_proto_*.c files.
>
> * Check for invalid flags set via NFQA_CFG_FLAGS in nfnetlink_queue
> from Krishna Kumar.
>
> * Allow to obtain conntrack statistics via ctnetlink from mysqlf. This
> supersedes /proc/net/stat/nf_conntrack and
> /proc/sys/net/netfilter/nf_conntrack_count.
>
> * Don't crash if we send a message to nfnetlink and there is not defined
> callback to handle such message. Instead, nfnetlink returns -EINVAL from
> Tomasz Bursztyka. This one does not really fix anything now, that's
> why I'm passing this via net-next.
>
> You can pull these changes from:
>
> git://1984.lsi.us.es/nf-next master
>
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [PATCH net-next V1 00/10] net/mlx4: Add flow-steering support
From: David Miller @ 2012-07-07 23:24 UTC (permalink / raw)
To: ogerlitz; +Cc: roland, yevgenyp, oren, netdev, amirv, hadarh
In-Reply-To: <1341497030-1818-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Thu, 5 Jul 2012 17:03:40 +0300
> This patch series from Hadar adds code to manage L2/L3/L4 network
> flow steering rules, a feature which is supported by the ConnectX-3 device.
>
> The series is built as follows:
>
> The first two patches deal with SRIOV resource tracker, whose mechanism
> is changed to use red-black tree instead of radix tree. The reason for
> this change is that the coming steering patches use flow IDs which are 64
> bits in size, where radix tree keys can't be 64bit on 32bit architecture,
> while RB tree can do that.
>
> Patch #3 is little re-design of the Ethernet driver multicast attachments
> flow to be more efficient and robust.
>
> The fourth patch does a re-org of the checks that deal with the current
> "older" steering modes such that we can easily add soon the new steering
> mode and the code remains easy to manage.
>
> Patch #5 adds the firmware commands for the new steering mode, which is
> called "device managed flow steeering".
>
> Patch 6 is the main patch of this series. It adds support for device-managed flow
> steering all across the place. We had to have this patch also to touch the mlx4
> IB driver, since the steering mode is global to the HCA -- so when being enabled,
> multicast attachment calls done by the IB driver into the mlx4 core driver,
> are now routed to the flow steering firmware commands whose API is a bit different,
> something that the IB driver had to be aware to. Following that, the 7th patch
> adds resource tracking for device-managed flow steering rules.
>
> The 8th patch adds promiscuous mode support under device-managed flow steering,
> next, the 9th patch adds implementation for the ethtool APIs for attaching
> L2/L3/L4 based flow steering rules, and the last patch adds support for drop
> action through ethtool.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] 6lowpan: Various bug fixes
From: David Miller @ 2012-07-07 23:25 UTC (permalink / raw)
To: tony.cheneau; +Cc: netdev, alex.bluesman.smirnov
In-Reply-To: <1341550225-13112-1-git-send-email-tony.cheneau@amnesiak.org>
You've provided no signoffs in your commit messages, please fix this up
and resubmit this entire series.
^ permalink raw reply
* Re: [PATCH net-next] asix: avoid copies in tx path
From: David Miller @ 2012-07-07 23:27 UTC (permalink / raw)
To: ming.lei; +Cc: eric.dumazet, netdev, gregkh, allan, trond, grundler
In-Reply-To: <CACVXFVOYgVG5cZE8YPn2z6_xu5akLvUURJ3_pE4Stbh7U8L_AA@mail.gmail.com>
From: Ming Lei <ming.lei@canonical.com>
Date: Fri, 6 Jul 2012 09:16:32 +0800
> On Thu, Jul 5, 2012 at 10:31 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> I noticed excess calls to skb_copy_expand() or memmove() in asix driver.
>>
>> This driver needs to push 4 bytes in front of frame (packet_len)
>> and maybe add 4 bytes after the end (if padlen is 4)
>>
>> So it should set needed_headroom & needed_tailroom to avoid
>> copies. But its not enough, because many packets are cloned
>> before entering asix_tx_fixup() and this driver use skb_cloned()
>> as a lazy way to check if it can push and put additional bytes in frame.
>>
>> Avoid skb_copy_expand() expensive call, using following rules :
>>
>> - We are allowed to push 4 bytes in headroom if skb_header_cloned()
>> is false (and if we have 4 bytes of headroom)
>>
>> - We are allowed to put 4 bytes at tail if skb_cloned()
>> is false (and if we have 4 bytes of tailroom)
>>
>> TCP packets for example are cloned, but skb_header_release()
>> was called in tcp stack, allowing us to use headroom for our needs.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
...
> Tested-by: Ming Lei <ming.lei@canonical.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: pull-request: can-next 2012-07-04
From: David Miller @ 2012-07-07 23:29 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <4FF45AA1.2040907@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 04 Jul 2012 17:00:49 +0200
> our third pull request for upcoming v3.6 net-next. First Oliver and me
> fix some sparse warnings, then 3 patches by Hui Wang and Shawn Guo
> which improve flexcan support and finally the patch by Rostislav Lisovy
> that adds CAN frame classifier.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] net: fix non-ANSI function declaration warning
From: Ben Hutchings @ 2012-07-08 0:16 UTC (permalink / raw)
To: David Miller
Cc: emilgoode, edumazet, mirq-linux, jpirko, therbert, netdev,
kernel-janitors
In-Reply-To: <20120707.161235.1181930264623743070.davem@davemloft.net>
On Sat, 2012-07-07 at 16:12 -0700, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Sat, 7 Jul 2012 20:57:29 +0100
>
> > On Sat, 2012-07-07 at 20:47 +0200, Emil Goode wrote:
> >> Sparse is warning about non-ANSI function declaration.
> >> Add void to the parameterless function.
> >>
> >> net/core/dev.c:1804:38: warning:
> >> non-ANSI function declaration of function
> >> 'netif_get_num_default_rss_queues'
> >
> > I also posted a patch for this (and another instance I found).
>
> But you were asked to fix up the comment formatting in on of those
> patches so you need to fix that up and resubmit the entire set.
You have got to be kidding. I fixed one thing, so I have to fix
another?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: fix non-ANSI function declaration warning
From: David Miller @ 2012-07-08 0:25 UTC (permalink / raw)
To: bhutchings
Cc: emilgoode, edumazet, mirq-linux, jpirko, therbert, netdev,
kernel-janitors
In-Reply-To: <1341706563.25597.170.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Sun, 8 Jul 2012 01:16:03 +0100
> On Sat, 2012-07-07 at 16:12 -0700, David Miller wrote:
>> From: Ben Hutchings <bhutchings@solarflare.com>
>> Date: Sat, 7 Jul 2012 20:57:29 +0100
>>
>> > On Sat, 2012-07-07 at 20:47 +0200, Emil Goode wrote:
>> >> Sparse is warning about non-ANSI function declaration.
>> >> Add void to the parameterless function.
>> >>
>> >> net/core/dev.c:1804:38: warning:
>> >> non-ANSI function declaration of function
>> >> 'netif_get_num_default_rss_queues'
>> >
>> > I also posted a patch for this (and another instance I found).
>>
>> But you were asked to fix up the comment formatting in on of those
>> patches so you need to fix that up and resubmit the entire set.
>
> You have got to be kidding. I fixed one thing, so I have to fix
> another?
You're fixing up a comment, fix it fully.
^ permalink raw reply
* Re: [PATCH] net: fix non-ANSI function declaration warning
From: David Miller @ 2012-07-08 0:26 UTC (permalink / raw)
To: bhutchings
Cc: emilgoode, edumazet, mirq-linux, jpirko, therbert, netdev,
kernel-janitors
In-Reply-To: <20120707.172539.1943659609718696447.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 07 Jul 2012 17:25:39 -0700 (PDT)
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Sun, 8 Jul 2012 01:16:03 +0100
>
>> On Sat, 2012-07-07 at 16:12 -0700, David Miller wrote:
>>> From: Ben Hutchings <bhutchings@solarflare.com>
>>> Date: Sat, 7 Jul 2012 20:57:29 +0100
>>>
>>> > On Sat, 2012-07-07 at 20:47 +0200, Emil Goode wrote:
>>> >> Sparse is warning about non-ANSI function declaration.
>>> >> Add void to the parameterless function.
>>> >>
>>> >> net/core/dev.c:1804:38: warning:
>>> >> non-ANSI function declaration of function
>>> >> 'netif_get_num_default_rss_queues'
>>> >
>>> > I also posted a patch for this (and another instance I found).
>>>
>>> But you were asked to fix up the comment formatting in on of those
>>> patches so you need to fix that up and resubmit the entire set.
>>
>> You have got to be kidding. I fixed one thing, so I have to fix
>> another?
>
> You're fixing up a comment, fix it fully.
And btw when you don't respond to someone who gives you feedback I
have to assume you agree with them and intend to fix it, and thus I
automatically move all of your patches to changes-requested state
in patchwork and that's the last I will look at them.
^ permalink raw reply
* RE: [PATCH net,1/1] hyperv: Add support for setting MAC from within guests
From: Haiyang Zhang @ 2012-07-08 0:29 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, netdev@vger.kernel.org, KY Srinivasan,
olaf@aepfle.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <1341620355.2923.46.camel@bwh-desktop.uk.solarflarecom.com>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Friday, July 06, 2012 8:19 PM
> To: Haiyang Zhang
> Cc: davem@davemloft.net; netdev@vger.kernel.org; KY Srinivasan;
> olaf@aepfle.de; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org
> Subject: Re: [PATCH net,1/1] hyperv: Add support for setting MAC from
> within guests
>
> On Fri, 2012-07-06 at 14:25 -0700, Haiyang Zhang wrote:
> > This adds support for setting synthetic NIC MAC address from within
> > Linux guests. Before using this feature, the option "spoofing of MAC
> address"
> > should be enabled at the Hyper-V manager / Settings of the synthetic
> > NIC.
> [...]
> > +int rndis_filter_set_device_mac(struct hv_device *hdev, char *mac) {
> [...]
> > + t = wait_for_completion_timeout(&request->wait_event, 5*HZ);
> > + if (t == 0) {
> > + netdev_err(ndev, "timeout before we got a set
> response...\n");
> > + /*
> > + * can't put_rndis_request, since we may still receive a
> > + * send-completion.
> > + */
> > + return -EBUSY;
> > + } else {
> > + set_complete = &request->response_msg.msg.set_complete;
> > + if (set_complete->status != RNDIS_STATUS_SUCCESS)
> > + ret = -EINVAL;
> [...]
>
> Is there a specific error code that indicates the hypervisor is configured not
> to allow MAC address changes? If so, shouldn't that be translated to return
> EPERM rather than EINVAL?
Will do.
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH next-next] ppp: change default for incoming protocol filter to NPMODE_DROP
From: Benjamin LaHaise @ 2012-07-08 0:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-ppp
In-Reply-To: <20120707.161504.686059289738005570.davem@davemloft.net>
On Sat, Jul 07, 2012 at 04:15:04PM -0700, David Miller wrote:
> From: Benjamin LaHaise <bcrl@kvack.org>
> Date: Fri, 6 Jul 2012 13:28:00 -0400
>
> > How about the following addition instead to provide a list of
> > protocols to disable?
>
> The userspace programs must accomodate all existing kernels, so
> the addition of this feature is rather pointless.
It's not existing kernels that this guards against, but the use of older
versions of the API users on new kernels that support additional protocols.
I'm in the middle of porting a PPP stack to using the ppp_generic interface,
and there is no way for me to prevent packet types for protocols which are
newly added to the kernel from getting these new packet types leaked. I
came across this exactly because I was testing this case. I suppose I can
ignore the issue, but I'd prefer to get it right since it is technically a
security hole that bypasses PPP session authentication.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: [net-next RFC V5 0/5] Multiqueue virtio-net
From: Ronen Hod @ 2012-07-08 8:19 UTC (permalink / raw)
To: Jason Wang
Cc: krkumar2, habanero, mashirle, kvm, mst, netdev, linux-kernel,
virtualization, edumazet, tahm, jwhan, davem, sri
In-Reply-To: <1341484194-8108-1-git-send-email-jasowang@redhat.com>
On 07/05/2012 01:29 PM, Jason Wang wrote:
> Hello All:
>
> This series is an update version of multiqueue virtio-net driver based on
> Krishna Kumar's work to let virtio-net use multiple rx/tx queues to do the
> packets reception and transmission. Please review and comments.
>
> Test Environment:
> - Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 8 cores 2 numa nodes
> - Two directed connected 82599
>
> Test Summary:
>
> - Highlights: huge improvements on TCP_RR test
Hi Jason,
It might be that the good TCP_RR results are due to the large number of sessions (50-250). Can you test it also with small number of sessions?
> - Lowlights: regression on small packet transmission, higher cpu utilization
> than single queue, need further optimization
>
> Analysis of the performance result:
>
> - I count the number of packets sending/receiving during the test, and
> multiqueue show much more ability in terms of packets per second.
>
> - For the tx regression, multiqueue send about 1-2 times of more packets
> compared to single queue, and the packets size were much smaller than single
> queue does. I suspect tcp does less batching in multiqueue, so I hack the
> tcp_write_xmit() to forece more batching, multiqueue works as well as
> singlequeue for both small transmission and throughput
Could it be that since the CPUs are not busy they are available for immediate handling of the packets (little batching)? In such scenario the CPU utilization is not really interesting. What will happen on a busy machine?
Ronen.
>
> - I didn't pack the accelerate RFS with virtio-net in this sereis as it still
> need further shaping, for the one that interested in this please see:
> http://www.mail-archive.com/kvm@vger.kernel.org/msg64111.html
>
> Changes from V4:
> - Add ability to negotiate the number of queues through control virtqueue
> - Ethtool -{L|l} support and default the tx/rx queue number to 1
> - Expose the API to set irq affinity instead of irq itself
>
> Changes from V3:
>
> - Rebase to the net-next
> - Let queue 2 to be the control virtqueue to obey the spec
> - Prodives irq affinity
> - Choose txq based on processor id
>
> References:
>
> - V4: https://lkml.org/lkml/2012/6/25/120
> - V3: http://lwn.net/Articles/467283/
>
> Test result:
>
> 1) 1 vm 2 vcpu 1q vs 2q, 1 - 1q, 2 - 2q, no pinning
>
> - Guest to External Host TCP STREAM
> sessions size throughput1 throughput2 norm1 norm2
> 1 64 650.55 655.61 100% 24.88 24.86 99%
> 2 64 1446.81 1309.44 90% 30.49 27.16 89%
> 4 64 1430.52 1305.59 91% 30.78 26.80 87%
> 8 64 1450.89 1270.82 87% 30.83 25.95 84%
> 1 256 1699.45 1779.58 104% 56.75 59.08 104%
> 2 256 4902.71 3446.59 70% 98.53 62.78 63%
> 4 256 4803.76 2980.76 62% 97.44 54.68 56%
> 8 256 5128.88 3158.74 61% 104.68 58.61 55%
> 1 512 2837.98 2838.42 100% 89.76 90.41 100%
> 2 512 6742.59 5495.83 81% 155.03 99.07 63%
> 4 512 9193.70 5900.17 64% 202.84 106.44 52%
> 8 512 9287.51 7107.79 76% 202.18 129.08 63%
> 1 1024 4166.42 4224.98 101% 128.55 129.86 101%
> 2 1024 6196.94 7823.08 126% 181.80 168.81 92%
> 4 1024 9113.62 9219.49 101% 235.15 190.93 81%
> 8 1024 9324.25 9402.66 100% 239.10 179.99 75%
> 1 2048 7441.63 6534.04 87% 248.01 215.63 86%
> 2 2048 7024.61 7414.90 105% 225.79 219.62 97%
> 4 2048 8971.49 9269.00 103% 278.94 220.84 79%
> 8 2048 9314.20 9359.96 100% 268.36 192.23 71%
> 1 4096 8282.60 8990.08 108% 277.45 320.05 115%
> 2 4096 9194.80 9293.78 101% 317.02 248.76 78%
> 4 4096 9340.73 9313.19 99% 300.34 230.35 76%
> 8 4096 9148.23 9347.95 102% 279.49 199.43 71%
> 1 16384 8787.89 8766.31 99% 312.38 316.53 101%
> 2 16384 9306.35 9156.14 98% 319.53 279.83 87%
> 4 16384 9177.81 9307.50 101% 312.69 230.07 73%
> 8 16384 9035.82 9188.00 101% 298.32 199.17 66%
> - TCP RR
> sessions size throughput1 throughput2 norm1 norm2
> 50 1 54695.41 84164.98 153% 1957.33 1901.31 97%
> 100 1 60141.88 88598.94 147% 2157.90 2000.45 92%
> 250 1 74763.56 135584.22 181% 2541.94 2628.59 103%
> 50 64 51628.38 82867.50 160% 1872.55 1812.16 96%
> 100 64 60367.73 84080.60 139% 2215.69 1867.69 84%
> 250 64 68502.70 124910.59 182% 2321.43 2495.76 107%
> 50 128 53477.08 77625.07 145% 1905.10 1870.99 98%
> 100 128 59697.56 74902.37 125% 2230.66 1751.03 78%
> 250 128 71248.74 133963.55 188% 2453.12 2711.72 110%
> 50 256 47663.86 67742.63 142% 1880.45 1735.30 92%
> 100 256 54051.84 68738.57 127% 2123.03 1778.59 83%
> 250 256 68250.06 124487.90 182% 2321.89 2598.60 111%
> - External Host to Guest TCP STRAM
> sessions size throughput1 throughput2 norm1 norm2
> 1 64 847.71 864.83 102% 57.99 57.93 99%
> 2 64 1690.82 1544.94 91% 80.13 55.09 68%
> 4 64 3434.98 3455.53 100% 127.17 89.00 69%
> 8 64 5890.19 6557.35 111% 194.70 146.52 75%
> 1 256 2094.04 2109.14 100% 130.73 127.14 97%
> 2 256 5218.13 3731.97 71% 219.15 114.02 52%
> 4 256 6734.51 9213.47 136% 227.87 208.31 91%
> 8 256 6452.86 9402.78 145% 224.83 207.77 92%
> 1 512 3945.07 4203.68 106% 279.72 273.30 97%
> 2 512 7878.96 8122.55 103% 278.25 231.71 83%
> 4 512 7645.89 9402.13 122% 252.10 217.42 86%
> 8 512 6657.06 9403.71 141% 239.81 214.89 89%
> 1 1024 5729.06 5111.21 89% 289.38 303.09 104%
> 2 1024 8097.27 8159.67 100% 269.29 242.97 90%
> 4 1024 7778.93 8919.02 114% 261.28 205.50 78%
> 8 1024 6458.02 9360.02 144% 221.26 208.09 94%
> 1 2048 6426.94 5195.59 80% 292.52 307.47 105%
> 2 2048 8221.90 9025.66 109% 283.80 242.25 85%
> 4 2048 7364.72 8527.79 115% 248.10 198.36 79%
> 8 2048 6760.63 9161.07 135% 230.53 205.12 88%
> 1 4096 7247.02 6874.21 94% 276.23 287.68 104%
> 2 4096 8346.04 8818.65 105% 281.49 254.81 90%
> 4 4096 6710.00 9354.59 139% 216.41 210.13 97%
> 8 4096 6265.69 9406.87 150% 206.69 210.92 102%
> 1 16384 8159.50 8048.79 98% 266.94 283.11 106%
> 2 16384 8525.66 8552.41 100% 294.36 239.27 81%
> 4 16384 6042.24 8447.86 139% 200.21 196.40 98%
> 8 16384 6432.63 9403.49 146% 211.48 206.13 97%
>
> 2) 1 vm 4 vcpu 1q vs 4q, 1 - 1q, 2 - 4q, no pinning
>
> - Guest to External Host TCP STREAM
> sessions size throughput1 throughput2 norm1 norm2
> 1 64 636.93 657.69 103% 23.55 24.42 103%
> 2 64 1457.46 1268.78 87% 30.97 26.02 84%
> 4 64 3062.86 2302.43 75% 41.00 29.64 72%
> 8 64 3107.68 2308.32 74% 41.62 29.07 69%
> 1 256 1743.50 1750.11 100% 59.00 56.63 95%
> 2 256 4582.61 2870.31 62% 92.47 51.97 56%
> 4 256 8440.96 4795.37 56% 135.10 56.39 41%
> 8 256 9240.31 6654.82 72% 144.76 74.89 51%
> 1 512 2918.25 2735.26 93% 91.08 86.47 94%
> 2 512 8978.32 5107.95 56% 200.00 94.97 47%
> 4 512 8850.39 6864.37 77% 190.32 101.09 53%
> 8 512 9270.30 8483.01 91% 193.44 118.73 61%
> 1 1024 4416.10 3679.70 83% 135.54 110.63 81%
> 2 1024 9085.20 8770.48 96% 242.23 175.59 72%
> 4 1024 9158.57 9011.56 98% 234.39 159.17 67%
> 8 1024 9345.89 9067.43 97% 233.35 138.73 59%
> 1 2048 8455.19 6077.94 71% 338.52 190.16 56%
> 2 2048 9223.32 8237.73 89% 270.00 198.27 73%
> 4 2048 9080.75 9257.63 101% 261.30 172.80 66%
> 8 2048 9177.39 8977.10 97% 256.89 147.50 57%
> 1 4096 8665.35 8394.78 96% 289.63 289.85 100%
> 2 4096 7850.73 8857.86 112% 253.33 252.62 99%
> 4 4096 9332.55 8508.37 91% 289.19 151.29 52%
> 8 4096 8482.30 9146.80 107% 255.41 156.02 61%
> 1 16384 8825.72 8778.26 99% 314.60 308.89 98%
> 2 16384 9283.85 8927.40 96% 316.48 246.98 78%
> 4 16384 7766.95 8708.06 112% 265.25 155.59 58%
> 8 16384 8945.55 8940.23 99% 298.45 151.32 50%
> - TCP_RR
> sessions size throughput1 throughput2 norm1 norm2
> 50 1 60848.70 81719.39 134% 2196.86 1551.05 70%
> 100 1 61886.19 81425.02 131% 2215.76 1517.52 68%
> 250 1 72058.41 162597.84 225% 2441.84 2278.14 93%
> 50 64 51646.93 74160.10 143% 1861.07 1322.22 71%
> 100 64 57574.86 83488.26 145% 2076.54 1479.79 71%
> 250 64 67583.35 138482.15 204% 2314.46 2022.83 87%
> 50 128 59931.51 71633.03 119% 2244.60 1309.18 58%
> 100 128 58329.80 73104.90 125% 2202.98 1329.52 60%
> 250 128 71021.55 161067.73 226% 2469.11 2205.28 89%
> 50 256 47509.24 64330.24 135% 1915.75 1269.90 66%
> 100 256 49293.03 68507.94 138% 1939.75 1263.64 65%
> 250 256 63169.07 138390.68 219% 2255.47 2098.13 93%
> - External Host to Guest TCP STREAM
> sessions size throughput1 throughput2 norm1 norm2
> 1 64 850.18 854.96 100% 56.94 58.25 102%
> 2 64 1659.12 1730.25 104% 81.65 67.57 82%
> 4 64 3254.70 3397.17 104% 118.57 76.21 64%
> 8 64 6251.97 6389.29 102% 207.68 104.21 50%
> 1 256 2029.14 2105.18 103% 116.45 119.69 102%
> 2 256 5412.02 4260.32 78% 240.87 139.73 58%
> 4 256 7777.28 8743.12 112% 263.20 174.65 66%
> 8 256 6459.51 9388.93 145% 218.94 158.37 72%
> 1 512 4566.31 4269.30 93% 274.74 289.83 105%
> 2 512 7444.52 8240.64 110% 286.24 243.74 85%
> 4 512 7722.29 9391.16 121% 261.96 180.36 68%
> 8 512 6228.50 9134.52 146% 209.17 161.00 76%
> 1 1024 4965.50 4953.68 99% 307.64 280.48 91%
> 2 1024 8270.08 7733.71 93% 288.32 197.04 68%
> 4 1024 7551.04 9394.58 124% 268.41 206.62 76%
> 8 1024 6307.78 9179.03 145% 216.67 159.63 73%
> 1 2048 5741.12 5948.80 103% 290.34 268.66 92%
> 2 2048 7932.79 8766.05 110% 262.96 215.90 82%
> 4 2048 6907.55 9255.97 133% 233.56 203.96 87%
> 8 2048 6037.22 9399.41 155% 197.14 164.09 83%
> 1 4096 7131.70 7535.10 105% 279.43 275.12 98%
> 2 4096 8109.17 9348.04 115% 274.29 211.49 77%
> 4 4096 6878.92 9319.13 135% 244.21 192.06 78%
> 8 4096 6265.92 9408.35 150% 211.85 159.26 75%
> 1 16384 8288.01 8596.39 103% 272.85 290.22 106%
> 2 16384 8166.29 9280.12 113% 277.04 236.61 85%
> 4 16384 6446.97 9382.22 145% 222.91 187.24 83%
> 8 16384 6066.98 9405.51 155% 198.98 157.09 78%
>
> 3) 2 vms each with 2 vcpus, 1q vs 2q - pin vhost/vcpu in the same node
>
> - 2 Guests to External Hosts TCP STREAM
> sessions size throughput1 throughput2 norm1 norm2
> 1 64 1442.07 1475.11 102% 30.82 31.21 101%
> 2 64 3124.87 2900.93 92% 40.29 35.95 89%
> 4 64 3166.52 2864.04 90% 40.70 35.47 87%
> 8 64 3141.45 2848.94 90% 40.38 35.34 87%
> 1 256 3628.54 3711.73 102% 68.47 70.22 102%
> 2 256 7806.95 7586.69 97% 111.23 84.38 75%
> 4 256 8823.65 7612.74 86% 132.92 85.04 63%
> 8 256 9194.89 9373.41 101% 135.98 119.62 87%
> 1 512 7106.67 7128.00 100% 124.79 124.30 99%
> 2 512 9190.22 9397.33 102% 180.84 149.34 82%
> 4 512 9401.01 9376.67 99% 173.00 140.15 81%
> 8 512 8572.84 9032.90 105% 150.49 127.58 84%
> 1 1024 9361.93 9379.24 100% 205.81 202.94 98%
> 2 1024 9386.69 9389.04 100% 201.78 165.75 82%
> 4 1024 9403.43 9378.54 99% 195.33 152.06 77%
> 8 1024 9213.63 9180.64 99% 178.99 141.51 79%
> 1 2048 9338.95 9384.67 100% 223.22 227.86 102%
> 2 2048 9389.28 9389.45 100% 202.37 170.08 84%
> 4 2048 9405.86 9388.71 99% 193.76 161.54 83%
> 8 2048 9352.40 9384.06 100% 189.16 157.06 83%
> 1 4096 9380.74 9384.90 100% 239.37 241.56 100%
> 2 4096 9393.47 9376.74 99% 213.84 195.61 91%
> 4 4096 9393.85 9381.50 99% 198.06 170.18 85%
> 8 4096 9400.41 9232.31 98% 192.87 163.56 84%
> 1 16384 9348.18 9335.55 99% 253.02 254.86 100%
> 2 16384 9384.97 9359.53 99% 218.56 208.59 95%
> 4 16384 9326.60 9382.15 100% 206.24 179.72 87%
> 8 16384 9355.82 9392.85 100% 198.22 172.89 87%
> - TCP RR
> sessions size throughput1 throughput2 norm1 norm2
> 50 1 200340.33 261750.19 130% 2935.27 3018.59 102%
> 100 1 236141.58 266304.49 112% 3452.16 3071.74 88%
> 250 1 361574.59 320825.08 88% 4972.98 3705.70 74%
> 50 64 225748.53 242671.12 107% 3011.48 2869.07 95%
> 100 64 249885.37 260453.72 104% 3240.21 3063.67 94%
> 250 64 360341.12 310775.60 86% 4682.42 3657.91 78%
> 50 128 227995.27 289320.38 126% 2950.92 3479.37 117%
> 100 128 239491.11 291135.77 121% 3099.55 3508.75 113%
> 250 128 390390.68 362484.35 92% 5042.30 4368.52 86%
> 50 256 222604.51 317140.97 142% 3058.08 3839.39 125%
> 100 256 254770.92 335606.03 131% 3326.16 4046.65 121%
> 250 256 400584.52 436749.22 109% 5220.79 5278.86 101%
> - External Host to 2 Guests
> sessions size throughput1 throughput2 norm1 norm2
> 1 64 1667.99 1684.50 100% 59.66 60.77 101%
> 2 64 3338.83 3379.97 101% 83.61 64.82 77%
> 4 64 6613.65 6619.11 100% 131.00 97.19 74%
> 8 64 6553.07 6418.31 97% 141.35 98.27 69%
> 1 256 3938.40 4068.52 103% 125.21 123.76 98%
> 2 256 9215.57 9210.88 99% 185.31 154.27 83%
> 4 256 9407.29 9008.13 95% 186.72 150.01 80%
> 8 256 9377.17 9385.57 100% 190.28 137.59 72%
> 1 512 7360.19 6984.80 94% 214.09 211.66 98%
> 2 512 9392.91 9401.88 100% 193.92 173.11 89%
> 4 512 9382.64 9394.34 100% 189.27 145.80 77%
> 8 512 9308.60 9094.08 97% 189.70 141.26 74%
> 1 1024 9153.26 9066.06 99% 223.07 219.95 98%
> 2 1024 9393.38 9398.43 100% 194.02 173.82 89%
> 4 1024 9395.92 8960.73 95% 192.61 145.82 75%
> 8 1024 9388.92 9399.08 100% 191.18 143.87 75%
> 1 2048 9355.32 9240.63 98% 221.50 223.03 100%
> 2 2048 9395.68 9399.62 100% 193.31 177.21 91%
> 4 2048 9397.67 9399.56 100% 195.25 157.53 80%
> 8 2048 9397.89 9401.70 100% 197.57 146.96 74%
> 1 4096 9375.84 9381.72 100% 223.06 225.06 100%
> 2 4096 9389.47 9396.00 100% 193.91 197.13 101%
> 4 4096 9397.45 9400.11 100% 192.33 163.60 85%
> 8 4096 9105.40 9415.76 103% 192.71 140.41 72%
> 1 16384 9381.53 9381.40 99% 223.53 225.66 100%
> 2 16384 9387.90 9395.44 100% 193.34 177.03 91%
> 4 16384 9397.92 9410.98 100% 195.04 151.14 77%
> 8 16384 9259.00 9419.48 101% 194.91 153.48 78%
>
> 4) Local vm to vm 2 vcpu 1q vs 2q - pin vcpu/thread in the same numa node
>
> - VM to VM TCP STREAM
> sessions size throughput1 throughput2 norm1 norm2
> 1 64 576.05 576.14 100% 12.25 12.32 100%
> 2 64 1266.75 1160.04 91% 19.10 16.05 84%
> 4 64 1267.34 1123.70 88% 19.08 15.51 81%
> 8 64 1230.88 1174.70 95% 18.53 15.58 84%
> 1 256 1311.00 1303.02 99% 25.34 25.35 100%
> 2 256 5400.26 2794.00 51% 75.92 36.43 47%
> 4 256 5200.67 2818.88 54% 72.81 33.92 46%
> 8 256 5234.55 2893.74 55% 73.10 34.97 47%
> 1 512 3244.09 3263.72 100% 56.48 56.65 100%
> 2 512 8172.16 4661.15 57% 119.05 67.89 57%
> 4 512 10567.44 7063.25 66% 147.76 77.27 52%
> 8 512 10477.87 8471.33 80% 145.94 102.91 70%
> 1 1024 5432.54 5333.99 98% 93.69 92.38 98%
> 2 1024 12590.24 9259.97 73% 185.37 135.28 72%
> 4 1024 15600.53 10731.93 68% 222.20 123.60 55%
> 8 1024 16222.87 10704.85 65% 227.05 113.81 50%
> 1 2048 6667.61 7484.37 112% 116.75 129.72 111%
> 2 2048 8180.43 11500.88 140% 137.84 156.64 113%
> 4 2048 15127.93 14416.16 95% 227.60 154.59 67%
> 8 2048 16381.79 14794.10 90% 244.29 158.45 64%
> 1 4096 7375.63 8948.90 121% 131.97 156.57 118%
> 2 4096 9321.16 14443.21 154% 161.24 163.74 101%
> 4 4096 13028.45 15984.94 122% 212.78 171.26 80%
> 8 4096 15611.28 18810.54 120% 245.15 198.65 81%
> 1 16384 15304.38 14202.08 92% 259.94 244.04 93%
> 2 16384 15508.97 15913.09 102% 261.30 244.26 93%
> 4 16384 14859.98 20164.34 135% 248.29 214.26 86%
> 8 16384 15594.59 19960.99 127% 253.79 211.27 83%
> - TCP RR
> sessions size throughput1 throughput2 norm1 norm2
> 50 1 54972.51 69820.99 127% 1133.58 1063.58 93%
> 100 1 55847.16 72407.93 129% 1155.73 1024.35 88%
> 250 1 60066.23 108266.50 180% 1114.30 1323.55 118%
> 50 64 48727.63 62378.32 128% 1014.29 888.78 87%
> 100 64 51804.65 69250.51 133% 1077.78 986.97 91%
> 250 64 61278.68 100015.78 163% 1076.93 1243.18 115%
> 50 256 51593.29 62046.22 120% 1069.14 871.08 81%
> 100 256 51647.00 68197.43 132% 1071.66 958.51 89%
> 250 256 60433.88 99072.59 163% 1072.41 1199.10 111%
> 50 512 52177.79 66483.77 127% 1082.65 960.82 88%
> 100 512 50351.67 62537.63 124% 1041.61 876.41 84%
> 250 512 60510.14 103856.79 171% 1055.21 1245.17 118%
>
>
> Jason Wang (4):
> virtio_ring: move queue_index to vring_virtqueue
> virtio: intorduce an API to set affinity for a virtqueue
> virtio_net: multiqueue support
> virtio_net: support negotiating the number of queues through ctrl vq
>
> Krishna Kumar (1):
> virtio_net: Introduce VIRTIO_NET_F_MULTIQUEUE
>
> drivers/net/virtio_net.c | 792 +++++++++++++++++++++++++++++------------
> drivers/virtio/virtio_mmio.c | 5 +-
> drivers/virtio/virtio_pci.c | 58 +++-
> drivers/virtio/virtio_ring.c | 17 +
> include/linux/virtio.h | 4 +
> include/linux/virtio_config.h | 21 ++
> include/linux/virtio_net.h | 10 +
> 7 files changed, 677 insertions(+), 230 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: IPV6 ndisc:: Bad NIC causing IPV6 NDP to stop working
From: Menny_Hamburger @ 2012-07-08 8:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1340270190.4604.4640.camel@edumazet-glaptop>
After some debugging we found that our network driver sometimes fails to release the skb after calls to tx_start_xmit, which caused the ndisc socket send buffer to become full.
(sock_alloc_send_skb would fail on (atomic_read(&sk->sk_wmwm_alloc) < sk->sk_sndbuf) ).
We also witnessed allocation failures in cases where we have a number of different NICS (1GB, 10GB, ...) - the slowest NIC becomes a bottleneck.
Using alloc_skb instead of sock_alloc_skb fixes this problem; my only concern is that in the extreme cases of a stray driver or some memory corruption, the absence of an upper limit to the skb
allocation may consume the skbuff cache and cause all networking to behave badly.
Thanks,
Menny
net/ipv6/ndisc.c | 24 ++++++------------------
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 69a6330..f149d85 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -429,7 +429,6 @@ struct sk_buff *ndisc_build_skb(struct net_device *dev,
int hlen = LL_RESERVED_SPACE(dev);
int tlen = dev->needed_tailroom;
int len;
- int err;
u8 *opt;
if (!dev->addr_len)
@@ -439,15 +438,10 @@ struct sk_buff *ndisc_build_skb(struct net_device *dev,
if (llinfo)
len += ndisc_opt_addr_space(dev);
- skb = sock_alloc_send_skb(sk,
- (MAX_HEADER + sizeof(struct ipv6hdr) +
- len + hlen + tlen),
- 1, &err);
- if (!skb) {
- ND_PRINTK(0, err, "ND: %s failed to allocate an skb, err=%d\n",
- __func__, err);
+ skb = alloc_skb(MAX_HEADER + sizeof(struct ipv6hdr) + len + hlen + tlen,
+ GFP_ATOMIC);
+ if (!skb)
return NULL;
- }
skb_reserve(skb, hlen);
ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len);
@@ -1550,16 +1544,10 @@ void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
hlen = LL_RESERVED_SPACE(dev);
tlen = dev->needed_tailroom;
- buff = sock_alloc_send_skb(sk,
- (MAX_HEADER + sizeof(struct ipv6hdr) +
- len + hlen + tlen),
- 1, &err);
- if (buff == NULL) {
- ND_PRINTK(0, err,
- "Redirect: %s failed to allocate an skb, err=%d\n",
- __func__, err);
+ buff = alloc_skb(MAX_HEADER + sizeof(struct ipv6hdr) + len + hlen + tlen,
+ GFP_ATOMIC);
+ if (!buff)
goto release;
- }
skb_reserve(buff, hlen);
ip6_nd_hdr(sk, buff, dev, &saddr_buf, &ipv6_hdr(skb)->saddr,
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox