RFE: Linux Bridge vhost-user support via fast path detection

[Maxime Leroy]

Fast path technology is a user-space stack for high performance packets offloading the Linux networking functions: IPv4/IPv6 routing, linux bridge, iptables, conntrack...

To benefit from the offloading, a VM needs to use vhost-user instead of vhost-net backend for virtio interfaces.

As a consequence, we have:

- a forked ML2 linux bridge mechanism driver: https://github.com/openstack/networking-6wind/blob/master/networking_6wind/ml2_drivers/linuxbridge/mech_driver/mech_lb_fp.py
- a forked linux agent: https://github.com/openstack/networking-6wind/blob/master/networking_6wind/ml2_drivers/linuxbridge/agent/lb_fp_neutron_agent.py.

Problem Description
===================

We need to maintain a fork version of the ML2 linux bridge mechanism driver and also one for the linux bridge agent , it is not a proper design.

From users point of view, having to install a specific mechanism driver and an agent to benefit of the fastpath offloading, it is an extra operation. We should avoid to add extra operation for easiness.

Proposed Change
===============

LinuxBridge Agent
-----------------

The linux bridge agent shall detect whether a fast path offload is enabled, and it shall report it to the mechanism driver with the use of agent_state.

For this capability, a new field will be added in agent_state.configuration: fp_offload.

ML2 LinuxBridge
---------------

The mechanism driver LinuxBridge in the try_bind_segment_for_agent will:

- set the vif_type to LINUXBRIDGE if agent['configuration']['fp_offload'] is False
- set the vif_type to VHOSTUSER if agent['configuration']['fp_offload'] is True

Specific vif_details needs to be added for vhost-user:

- vhost_user_socket (i.e '/tmp/usv-XXXX')
- vhost_user_fp_plug should be set True to create a tap netdevice with a vhostuser socket

Note: The vhost_user_fp_plug is a modification under review in Nova. See: https://review.openstack.org/#/c/245369/

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/246536

[Cedric Brandily (cbrandily)]

Could you explain why this should live in neutron when we move out-of-tree vendor code? And why you currently need to fork LB mechanism and agent when you could define a mechanism/agent to manage agents supporting offload and let existing LB mechanism/agent manage agents not supporting offload

[Maxime Leroy (maxime-leroy)]

@Cedric

First, we don't need any specific modifications on the LB agent regarding the configuration of the bridge. Standard linux commands (i.e. brctl, ip ...) works with our offloading solution.

But, if we use the officiel LB agent, our ML2 mechanism driver will not be able to know which compute node is running
linux bridge or linux bridge + fast path offload. So the LB ML2 mech and LB fast path ML2 mech cannot work together in this case.

At least, we need to modify the agent_type in the LB agent. To do that in networking-6wind, we have a new class (called LinuxBridgeFPNeutronAgentRPC) heriting of LinuxBridgeNeutronAgentRPC to modify the agent_type reported to the mechanism driver. And we also needs to copy the main function of linuxbridge_neutron_agent into our an agent.

An alternative is to add an agent_type configuration option for the linux bridge agent. It will allows us to set a specific agent type. A similar patch has been merged for open vswitch agent in liberty. See: https://review.openstack.org/#/c/197210/

But the final user still needs to install a specific mechanism driver and set the agent_type with the proper value. Any error typo on the agent type option will cause the ML2 LB FP mech driver ignore this agent.

Adding a way to detect at run time if the fast path offload is supported and report it to the ML2 LB mech driver to choose which VIF_TYPE (i.e. BRIDGE or VHOSTUSER) seems to be a nicer solution for the user.

[Armando Migliaccio (armando-migliaccio)]

The way I understand this, is that you'd want the linuxbridge agent to supported a custom environment where you run proprietary technology. There can be similarities where, right now, you are making small changes to the upstream LB agent to allow your solution to work with the upstream tools (without forking). But this strategy is a slippery slope and it gives you the least flexibility because later on you might realize that more is needed and more changes have to go upstream...when is this going to end, or where do we draw the line?

For this reason, I think is dangerous contemplating the idea that an open source tool designed with certain assumptions in mind (stock upstream vanilla components) can work with proprietary (accelerated) components.

Right now, I believe this is a distraction to all the other initiatives that revolve around LB and OVS, and for this reason I am against it.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Doug Wiegley (<email address hidden>) on branch: master
Review: https://review.openstack.org/246536
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.