Dropping privileges in openvswitch-switch via --user is incompatible with --dpdk

Bug #1546556 reported by Christian Ehrhardt  on 2016-02-17
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack neutron-openvswitch charm
Wishlist
Unassigned
dpdk (Ubuntu)
Wishlist
Unassigned
openvswitch-dpdk (Ubuntu)
Wishlist
Unassigned

Bug Description

Openvswitch has a nice security feature where one can drop privileges via --user option.
Unfortunately due to the nature of DPDK it needs root permissions to initialize most of its resources.
Thereby --dpdk and --user are mutually exclusive.

There are upstream discussions ongoing if it could first initialize DPDK and then drop permissions.
But then it was identified that this would imply no adding/removing of dpdk devices at runtime.
So the discussions go on for now.

Once an upstream solution is ready we can decide if we backport or wait until we merge a newer version - therefore just wishlist for now.

Changed in dpdk (Ubuntu):
status: New → Triaged
Changed in openvswitch-dpdk (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
Changed in dpdk (Ubuntu):
importance: Undecided → Wishlist
Thiago Martins (martinx) wrote :

Guys,

I'm trying to use OVS with DPDK to create a bridge between 2 x 10G NIC cards, however, it is not working, the log shows:

---
root@xenial-1:~# ovs-vswitchd log
2016-03-08T04:19:19Z|00001|ovs_numa|INFO|Discovered 24 CPU cores on NUMA node 0
2016-03-08T04:19:19Z|00002|ovs_numa|INFO|Discovered 24 CPU cores on NUMA node 1
2016-03-08T04:19:19Z|00003|ovs_numa|INFO|Discovered 2 NUMA nodes and 48 CPU cores
2016-03-08T04:19:19Z|00004|reconnect|INFO|log: connecting...
2016-03-08T04:19:19Z|00005|reconnect|INFO|log: connection attempt failed (Address family not supported by protocol)
2016-03-08T04:19:19Z|00006|reconnect|INFO|log: waiting 1 seconds before reconnect
2016-03-08T04:19:20Z|00007|reconnect|INFO|log: connecting...
2016-03-08T04:19:20Z|00008|reconnect|INFO|log: connection attempt failed (Address family not supported by protocol)
2016-03-08T04:19:20Z|00009|reconnect|INFO|log: waiting 2 seconds before reconnect
2016-03-08T04:19:22Z|00010|reconnect|INFO|log: connecting...
2016-03-08T04:19:22Z|00011|reconnect|INFO|log: connection attempt failed (Address family not supported by protocol)
2016-03-08T04:19:22Z|00012|reconnect|INFO|log: waiting 4 seconds before reconnect
2016-03-08T04:19:23Z|00013|fatal_signal|WARN|terminating with signal 2 (Interrupt)
---

After a bit of research on the Internet, I'm thinking that it might be related to this problem... Or not?

Hi Thiago,
when running into the issue the bug is referring to it looked way different.
So I'd say the issue you are currently facing has nothing to do with the bug.

I've seen your mail on the List and will reply there with some suggestions and by that keep the bug to the related things.

Long term FYI - I've just seen some patches on early DPDK init upstream at ovs-devel ML.
Depending how OVS2.7 and DPDK 16.11 continue this might work in the next pair of releases.

To some extend this could be a way out.

https://github.com/openvswitch/ovs/commit/e3e738a3d0580a9a7178adfc9300a193b8df4ae5

Need to check on that somewhen in 18.04 cycle.

Old bug update, this works as-is.
You can run as non-root - the old need for socket ownership also vanished due to the swicth to vhostuserclient.

To the extend of what I wanted this would work, although it might have some rough edges left to configure it properly.
(I'm unsure what the charms do these days)

Changed in dpdk (Ubuntu):
status: Triaged → Fix Released
Changed in openvswitch-dpdk (Ubuntu):
status: Triaged → Fix Released

Added a "neutron-openvswitch charm" task so that we can think if we want to test if that could really work non-root (or does already) and if we would want some work there.
Functionally (as mentioned above) everything should be there nowadays.

Changed in charm-neutron-openvswitch:
status: New → Triaged
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers