yahoo-eng-team team mailing list archive

[Armando Migliaccio <1517146@xxxxxxxxxxxxxxxxxx>]

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.


** Changed in: neutron
       Status: In Progress => Won't Fix

** Changed in: neutron
     Assignee: Maxime Leroy (maxime-leroy) => (unassigned)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1517146

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

Status in networking-6wind:
  New
Status in neutron:
  Won't Fix

Bug description:
  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/

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-6wind/+bug/1517146/+subscriptions