| 2013-07-16 16:08:10 |
Chris J Arges |
bug |
|
|
added bug |
| 2013-07-16 16:09:40 |
Chris J Arges |
nominated for series |
|
Ubuntu Quantal |
|
| 2013-07-16 16:09:40 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Quantal) |
|
| 2013-07-16 16:09:40 |
Chris J Arges |
nominated for series |
|
Ubuntu Raring |
|
| 2013-07-16 16:09:40 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Raring) |
|
| 2013-07-16 16:09:46 |
Chris J Arges |
linux (Ubuntu): assignee |
Chris J Arges (arges) |
|
|
| 2013-07-16 16:09:51 |
Chris J Arges |
linux (Ubuntu): status |
New |
Fix Released |
|
| 2013-07-16 16:09:54 |
Chris J Arges |
linux (Ubuntu Quantal): status |
New |
In Progress |
|
| 2013-07-16 16:09:57 |
Chris J Arges |
linux (Ubuntu Raring): status |
New |
In Progress |
|
| 2013-07-16 16:10:01 |
Chris J Arges |
linux (Ubuntu Raring): assignee |
|
Chris J Arges (arges) |
|
| 2013-07-16 16:10:05 |
Chris J Arges |
linux (Ubuntu Quantal): assignee |
|
Chris J Arges (arges) |
|
| 2013-07-16 16:10:08 |
Chris J Arges |
linux (Ubuntu Raring): importance |
Undecided |
Medium |
|
| 2013-07-16 16:10:13 |
Chris J Arges |
linux (Ubuntu Quantal): importance |
Undecided |
Medium |
|
| 2013-07-16 17:08:47 |
Mark Russell |
bug |
|
|
added subscriber Mark Russell |
| 2013-07-16 20:46:45 |
Mark Russell |
bug |
|
|
added subscriber Canonical Support |
| 2013-07-18 14:02:41 |
Chris J Arges |
description |
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (3.9) throughput is much higher.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
SRU Justification:
Impact:
Users of the 3.5/3.8 kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These patches are all in Ubuntu-3.9.0-7.15 / v3.9-rc1:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
|
| 2013-07-18 20:35:22 |
Chris J Arges |
description |
SRU Justification:
Impact:
Users of the 3.5/3.8 kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These patches are all in Ubuntu-3.9.0-7.15 / v3.9-rc1:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
SRU Justification:
Impact:
Users of the 3.5/3.8 kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These patches are all in Ubuntu-3.9.0-7.15 / v3.9-rc1:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
|
| 2013-07-21 18:05:42 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto MURATA |
| 2013-08-01 13:05:15 |
Brad Figg |
tags |
bot-stop-nagging |
bot-stop-nagging verification-needed-quantal |
|
| 2013-08-01 13:10:28 |
Brad Figg |
tags |
bot-stop-nagging verification-needed-quantal |
bot-stop-nagging verification-needed-quantal verification-needed-raring |
|
| 2013-08-11 00:19:36 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/quantal-proposed/linux-ti-omap4 |
|
| 2013-08-12 16:16:49 |
Brad Figg |
linux (Ubuntu Quantal): status |
In Progress |
Fix Committed |
|
| 2013-08-12 16:16:53 |
Brad Figg |
linux (Ubuntu Raring): status |
In Progress |
Fix Committed |
|
| 2013-08-13 16:02:02 |
Chris J Arges |
tags |
bot-stop-nagging verification-needed-quantal verification-needed-raring |
bot-stop-nagging kernel-key verification-needed-quantal verification-needed-raring |
|
| 2013-08-13 16:24:18 |
Chris J Arges |
tags |
bot-stop-nagging kernel-key verification-needed-quantal verification-needed-raring |
bot-stop-nagging kernel-key verification-failed-quantal verification-failed-raring |
|
| 2013-08-13 16:41:10 |
Joseph Salisbury |
tags |
bot-stop-nagging kernel-key verification-failed-quantal verification-failed-raring |
bot-stop-nagging kernel-key quantal raring verification-failed-quantal verification-failed-raring |
|
| 2013-08-13 16:41:40 |
Joseph Salisbury |
linux (Ubuntu): importance |
Undecided |
Medium |
|
| 2013-08-19 20:21:12 |
Launchpad Janitor |
linux (Ubuntu Quantal): status |
Fix Committed |
Fix Released |
|
| 2013-08-19 20:21:12 |
Launchpad Janitor |
cve linked |
|
2013-1059 |
|
| 2013-08-19 20:21:12 |
Launchpad Janitor |
cve linked |
|
2013-2148 |
|
| 2013-08-19 20:21:12 |
Launchpad Janitor |
cve linked |
|
2013-2851 |
|
| 2013-08-19 20:49:45 |
Adam Conrad |
linux (Ubuntu Quantal): status |
Fix Released |
In Progress |
|
| 2013-08-20 09:14:00 |
Launchpad Janitor |
linux (Ubuntu Raring): status |
Fix Committed |
Fix Released |
|
| 2013-08-20 09:14:00 |
Launchpad Janitor |
cve linked |
|
2013-4125 |
|
| 2013-08-20 09:14:00 |
Launchpad Janitor |
cve linked |
|
2013-4127 |
|
| 2013-08-20 15:46:21 |
Joseph Salisbury |
tags |
bot-stop-nagging kernel-key quantal raring verification-failed-quantal verification-failed-raring |
bot-stop-nagging quantal raring verification-failed-quantal verification-failed-raring |
|
| 2013-08-21 21:10:37 |
Chris J Arges |
linux (Ubuntu Raring): status |
Fix Released |
In Progress |
|
| 2013-08-23 20:33:24 |
Chris J Arges |
tags |
bot-stop-nagging quantal raring verification-failed-quantal verification-failed-raring |
bot-stop-nagging quantal raring |
|
| 2013-08-23 20:33:31 |
Chris J Arges |
description |
SRU Justification:
Impact:
Users of the 3.5/3.8 kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These patches are all in Ubuntu-3.9.0-7.15 / v3.9-rc1:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
SRU Justification:
Impact:
Users of the 3.5/3.8 kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
|
| 2013-09-16 14:21:04 |
Brad Figg |
tags |
bot-stop-nagging quantal raring |
bot-stop-nagging quantal raring verification-needed-quantal |
|
| 2013-09-16 14:21:44 |
Brad Figg |
tags |
bot-stop-nagging quantal raring verification-needed-quantal |
bot-stop-nagging quantal raring verification-needed-quantal verification-needed-raring |
|
| 2013-09-21 00:31:03 |
Mark Russell |
tags |
bot-stop-nagging quantal raring verification-needed-quantal verification-needed-raring |
bot-stop-nagging quantal raring verification-done-quantal verification-needed-raring |
|
| 2013-09-21 00:31:32 |
Mark Russell |
tags |
bot-stop-nagging quantal raring verification-done-quantal verification-needed-raring |
bot-stop-nagging quantal raring verification-needed-raring verification-quantal-done |
|
| 2013-09-21 16:33:20 |
Chris J Arges |
tags |
bot-stop-nagging quantal raring verification-needed-raring verification-quantal-done |
bot-stop-nagging quantal raring verification-done-quantal verification-needed-raring |
|
| 2013-09-22 00:28:15 |
Brad Figg |
linux (Ubuntu Quantal): status |
In Progress |
Fix Committed |
|
| 2013-09-22 00:28:17 |
Brad Figg |
linux (Ubuntu Raring): status |
In Progress |
Fix Committed |
|
| 2013-09-23 14:21:33 |
Brad Figg |
tags |
bot-stop-nagging quantal raring verification-done-quantal verification-needed-raring |
bot-stop-nagging quantal raring verification-done-quantal verification-done-raring |
|
| 2013-09-27 09:20:50 |
Launchpad Janitor |
linux (Ubuntu Quantal): status |
Fix Committed |
Fix Released |
|
| 2013-09-27 09:20:50 |
Launchpad Janitor |
cve linked |
|
2013-1819 |
|
| 2013-09-27 09:20:50 |
Launchpad Janitor |
cve linked |
|
2013-4254 |
|
| 2013-09-27 09:23:15 |
Launchpad Janitor |
linux (Ubuntu Raring): status |
Fix Committed |
Fix Released |
|
| 2014-03-25 20:02:55 |
Chris J Arges |
nominated for series |
|
Ubuntu Precise |
|
| 2014-03-25 20:02:55 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Precise) |
|
| 2014-03-25 20:04:44 |
Chris J Arges |
description |
SRU Justification:
Impact:
Users of the 3.5/3.8 kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
|
| 2014-03-25 20:08:02 |
Chris J Arges |
description |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
Another testcase without Openstack:
* create two vms: (vm1, vm2), install iperf on those machines
* connect vms via an isolated bridge
* measure baseline performance
- iperf -s # on machine 1
- iperf -t 60 -l 4M -c <machine 1 IP> # on machine 2
* create veth pairs between vms using attached script:
- ./setup-lp1201869.sh vm1
- ./setup-lp1201869.sh vm2
* In the VM's setup static IPs
- sudo ifconfig eth0 10.10.10.1/24 up #vm1
- sudo ifconfig eth0 10.10.10.2/24 up #vm2
* measure performance now
* we expect this to be close to the existing performance
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
|
| 2014-03-25 20:08:11 |
Chris J Arges |
linux (Ubuntu Precise): assignee |
|
Chris J Arges (arges) |
|
| 2014-03-25 20:08:14 |
Chris J Arges |
linux (Ubuntu Precise): status |
New |
In Progress |
|
| 2014-03-25 20:08:16 |
Chris J Arges |
linux (Ubuntu Precise): importance |
Undecided |
Medium |
|
| 2014-03-25 20:08:32 |
Chris J Arges |
attachment added |
|
setup-lp1201869.sh https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1201869/+attachment/4043420/+files/setup-lp1201869.sh |
|
| 2014-03-25 20:09:01 |
Chris J Arges |
summary |
poor networking throughput across an OpenStack Neutron router on 3.5/3.8 kernels |
poor networking throughput through veth interfaces |
|
| 2014-03-25 20:10:25 |
Chris J Arges |
description |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
Another testcase without Openstack:
* create two vms: (vm1, vm2), install iperf on those machines
* connect vms via an isolated bridge
* measure baseline performance
- iperf -s # on machine 1
- iperf -t 60 -l 4M -c <machine 1 IP> # on machine 2
* create veth pairs between vms using attached script:
- ./setup-lp1201869.sh vm1
- ./setup-lp1201869.sh vm2
* In the VM's setup static IPs
- sudo ifconfig eth0 10.10.10.1/24 up #vm1
- sudo ifconfig eth0 10.10.10.2/24 up #vm2
* measure performance now
* we expect this to be close to the existing performance
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Minimally 8093315a91340bca52549044975d8c7f673b28a1 provides the proper features to increase performance dramatically.
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
Another testcase without Openstack:
* create two vms: (vm1, vm2), install iperf on those machines
* connect vms via an isolated bridge
* measure baseline performance
- iperf -s # on machine 1
- iperf -t 60 -l 4M -c <machine 1 IP> # on machine 2
* create veth pairs between vms using attached script:
- ./setup-lp1201869.sh vm1
- ./setup-lp1201869.sh vm2
* In the VM's setup static IPs
- sudo ifconfig eth0 10.10.10.1/24 up #vm1
- sudo ifconfig eth0 10.10.10.2/24 up #vm2
* measure performance now
* we expect this to be close to the existing performance
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
|
| 2014-03-25 20:16:14 |
Chris J Arges |
description |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Minimally 8093315a91340bca52549044975d8c7f673b28a1 provides the proper features to increase performance dramatically.
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
Another testcase without Openstack:
* create two vms: (vm1, vm2), install iperf on those machines
* connect vms via an isolated bridge
* measure baseline performance
- iperf -s # on machine 1
- iperf -t 60 -l 4M -c <machine 1 IP> # on machine 2
* create veth pairs between vms using attached script:
- ./setup-lp1201869.sh vm1
- ./setup-lp1201869.sh vm2
* In the VM's setup static IPs
- sudo ifconfig eth0 10.10.10.1/24 up #vm1
- sudo ifconfig eth0 10.10.10.2/24 up #vm2
* measure performance now
* we expect this to be close to the existing performance
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
Another testcase without Openstack:
* create two vms: (vm1, vm2), install iperf on those machines
* connect vms via an isolated bridge
* measure baseline performance
- iperf -s # on machine 1
- iperf -t 60 -l 4M -c <machine 1 IP> # on machine 2
* create veth pairs between vms using attached script:
- ./setup-lp1201869.sh vm1
- ./setup-lp1201869.sh vm2
* In the VM's setup static IPs
- sudo ifconfig eth0 10.10.10.1/24 up #vm1
- sudo ifconfig eth0 10.10.10.2/24 up #vm2
* measure performance now
* we expect this to be close to the existing performance
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
|
| 2014-03-25 20:17:29 |
Bryan Quigley |
bug |
|
|
added subscriber Bryan Quigley |
| 2014-04-01 06:07:51 |
Xiang Hui |
bug |
|
|
added subscriber Xiang Hui |
| 2014-04-08 15:42:06 |
Brad Figg |
tags |
bot-stop-nagging quantal raring verification-done-quantal verification-done-raring |
bot-stop-nagging quantal raring verification-done-quantal verification-done-raring verification-needed-precise |
|
| 2014-04-08 22:30:29 |
Chris J Arges |
description |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
Another testcase without Openstack:
* create two vms: (vm1, vm2), install iperf on those machines
* connect vms via an isolated bridge
* measure baseline performance
- iperf -s # on machine 1
- iperf -t 60 -l 4M -c <machine 1 IP> # on machine 2
* create veth pairs between vms using attached script:
- ./setup-lp1201869.sh vm1
- ./setup-lp1201869.sh vm2
* In the VM's setup static IPs
- sudo ifconfig eth0 10.10.10.1/24 up #vm1
- sudo ifconfig eth0 10.10.10.2/24 up #vm2
* measure performance now
* we expect this to be close to the existing performance
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
Another testcase without Openstack:
* create two vms: (vm1, vm2), install iperf on those machines
* connect vms via an isolated bridge
* measure baseline performance
- iperf -s # on machine 1
- iperf -t 60 -l 4M -c <machine 1 IP> # on machine 2
* create veth pairs between vms using attached script:
- ./setup-lp1201869.sh vm1
- ./setup-lp1201869.sh vm2
* attach VM's interfaces to the created bridges (qbrvm1 / qbrvm2)
* In the VM's setup static IPs
- sudo ifconfig eth0 10.10.10.1/24 up #vm1
- sudo ifconfig eth0 10.10.10.2/24 up #vm2
* measure performance now
* we expect this to be close to the existing performance
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
|
| 2014-04-09 13:33:00 |
Tim Gardner |
linux (Ubuntu Precise): status |
In Progress |
Fix Committed |
|
| 2014-04-09 14:08:17 |
Chris J Arges |
description |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
Another testcase without Openstack:
* create two vms: (vm1, vm2), install iperf on those machines
* connect vms via an isolated bridge
* measure baseline performance
- iperf -s # on machine 1
- iperf -t 60 -l 4M -c <machine 1 IP> # on machine 2
* create veth pairs between vms using attached script:
- ./setup-lp1201869.sh vm1
- ./setup-lp1201869.sh vm2
* attach VM's interfaces to the created bridges (qbrvm1 / qbrvm2)
* In the VM's setup static IPs
- sudo ifconfig eth0 10.10.10.1/24 up #vm1
- sudo ifconfig eth0 10.10.10.2/24 up #vm2
* measure performance now
* we expect this to be close to the existing performance
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
SRU Justification:
Impact:
Users of the 3.2/3.5/3.8 series kernel will have poor network throughput when using OpenStack Neutron depending on their setup.
Fix:
These upstream patches are necessary to fix the issue:
2681128f0ced8aa4e66f221197e183cc16d244fe
8093315a91340bca52549044975d8c7f673b28a1
d0e2c55e7c940a3ee91e9e23a2683b593690f1e9
2efd32ee1b60b0b31404ca47c1ce70e5a5d24ebc
f45a5c267da35174e22cec955093a7513dc1623d
Testcase:
Setup OpenStack Neutron. Test throughput between internal and external nodes.
The following explains an example vlan+namespace configuration:
Internal Node: [10.x.x.2]->eth2.123->br123->tap123->qr-123[10.x.x.1] <--- netns: qrouter-123
netns: qrouter-123 ---> qg-234[10.x.y.1]->tap234->br234->eth2.234->External Node[10.x.y.2]
Where:
1) tap123+qr-123 and tap234+qg-234 are veth pairs
2) qr-123 and qg-234 reside inside the qrouter-123 namespace
Another testcase without Openstack:
* create two vms: (vm1, vm2), install iperf on those machines
* connect vms via an isolated bridge
* measure baseline performance
- iperf -s # on machine 1
- iperf -t 60 -l 4M -c <machine 1 IP> # on machine 2
* create veth pairs between vms using attached script:
- ./setup-lp1201869.sh vm1
- ./setup-lp1201869.sh vm2
* attach VM's interfaces to the created bridges (qbrvm1 / qbrvm2)
* In the VM's setup static IPs
- sudo ifconfig eth0 10.10.10.1/24 up #vm1
- sudo ifconfig eth0 10.10.10.2/24 up #vm2
* measure performance now
* we expect this to be close to the existing performance
NOTE: the fixed kernel needs to be on the _hypervisor_
--
OpenStack Neutron does IP forwarding through a network namespace. A veth pair is used to connect into the namespace. The veth pair appears to be the bottleneck, independent of network namespace. In newer versions of Linux (Ubuntu-3.9.0-7.15 / v3.9-rc1 and greater) throughput is much higher by almost 3 times. For example with some testing throughput is 3.5 Gbps in pre 3.9-rc1 versions and 9.1 Gbps with these patches applied.
This has been confirmed on kernels from 3.5.x-3.8.x. (Quantal and Raring lts backports) |
|
| 2014-04-09 14:26:20 |
Chris J Arges |
tags |
bot-stop-nagging quantal raring verification-done-quantal verification-done-raring verification-needed-precise |
bot-stop-nagging quantal raring verification-done-precise verification-done-quantal verification-done-raring |
|
| 2014-04-24 23:08:56 |
Launchpad Janitor |
linux (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
