neutron/neutron/plugins/ml2
Slawek Kaplonski 196ab6bea1 Fix ingress bandwidth limit in the openvswitch agent
For ingress bandwidth limiting openvswitch agent is using QoS and queues
from the Open vSwitch. There is always queue 0 used for that purpose.
Initially, when this feature was implemented, we assumed that queue 0 is
kind of the "default" queue to which all traffic will be send if there
are no other queues. But that's not true thus ingress bandwidth limiting
wasn't working properly with this agent.

This patch fixes that issue but adding in the table=0 of the br-int
additional OF rule to send all traffic to the queue 0.
In this queue for some ports there can be QoS configured
and then it will be applied for the port. If port don't have any QoS
configured, nothing will happen and all will work like before this
patch.

Biggest problem with that solution was the case when also ports with
minimum bandwidth are on the same node becuase such ports are using
different queues (queue number is the same as ofport number of the tap
interface).
In case when traffic is going from the port with minimum bandwidth QoS
to the port which has ingress bw limit configured, traffic is going only
through br-int and will use queue 0 to apply ingress bw limit properly.
In case when traffic from port with minimum bandwidth set needs to go
out from the host, it will always use physical bridge (minimum bandwidth
is only supported for the provider networks) and proper queue will be
set for such traffic in the physical bridge.
To be able to set proper queue in the physical bridge, this patch adds
additional OF rule to the br-int to set queue_num value in the pkt_mark
field [1] as this seems to be only field which can "survive" passing
bridges.

[1] https://man7.org/linux/man-pages/man7/ovs-fields.7.html

Conflicts:
    neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py

Closes-Bug: #1959567
Change-Id: I1e31565475f38c6ad817268699b165759ac05410
(cherry picked from commit f7ab90baad)
(cherry picked from commit 5573230d30)
(cherry picked from commit 4a0ca56fe5)
(cherry picked from commit e59a7d5c3d)
2022-04-05 14:10:46 +00:00
..
common Utilize bulk port creation ops in ml2 plugin 2019-03-21 11:31:36 +00:00
drivers Fix ingress bandwidth limit in the openvswitch agent 2022-04-05 14:10:46 +00:00
extensions Start enforcing E125 flake8 directive 2019-07-19 23:39:41 -04:00
README Metaplugin removal 2015-07-23 19:05:05 +09:00
__init__.py Empty files should not contain copyright or license 2014-10-20 00:50:32 +00:00
db.py Auto-delete dhcp ports on segment delete 2020-07-13 12:43:04 +02:00
driver_context.py Drive binding by placement allocation 2019-03-09 22:03:51 +00:00
managers.py Add "project_id" filter when changing the network segmentation ID 2020-03-05 15:51:21 +00:00
models.py Pluralize binding relationship in Port 2018-07-13 19:37:36 -05:00
ovo_rpc.py [Train Only] Fix queue import error issue 2022-01-20 11:36:46 +05:30
plugin.py [OVN] Check new added segments in OVN mech driver 2022-01-18 11:32:46 +00:00
rpc.py Only notify nova of port status changes if configured 2019-09-13 19:54:56 +00:00

README

The Modular Layer 2 (ML2) plugin is a framework allowing OpenStack
Networking to simultaneously utilize the variety of layer 2 networking
technologies found in complex real-world data centers. It supports the
Open vSwitch, Linux bridge, and Hyper-V L2 agents, replacing and
deprecating the monolithic plugins previously associated with those
agents, and can also support hardware devices and SDN controllers. The
ML2 framework is intended to greatly simplify adding support for new
L2 networking technologies, requiring much less initial and ongoing
effort than would be required for an additional monolithic core
plugin. It is also intended to foster innovation through its
organization as optional driver modules.

The ML2 plugin supports all the non-vendor-specific neutron API
extensions, and works with the standard neutron DHCP agent. It
utilizes the service plugin interface to implement the L3 router
abstraction, allowing use of either the standard neutron L3 agent or
alternative L3 solutions. Additional service plugins can also be used
with the ML2 core plugin.

Drivers within ML2 implement separately extensible sets of network
types and of mechanisms for accessing networks of those
types. Multiple mechanisms can be used simultaneously to access
different ports of the same virtual network. Mechanisms can utilize L2
agents via RPC and/or interact with external devices or
controllers. By utilizing the multiprovidernet extension, virtual
networks can be composed of multiple segments of the same or different
types. Type and mechanism drivers are loaded as python entrypoints
using the stevedore library.

Each available network type is managed by an ML2 type driver.  Type
drivers maintain any needed type-specific network state, and perform
provider network validation and tenant network allocation. As of the
havana release, drivers for the local, flat, vlan, gre, and vxlan
network types are included.

Each available networking mechanism is managed by an ML2 mechanism
driver. All registered mechanism drivers are called twice when
networks, subnets, and ports are created, updated, or deleted. They
are first called as part of the DB transaction, where they can
maintain any needed driver-specific state. Once the transaction has
been committed, they are called again, at which point they can
interact with external devices and controllers. Mechanism drivers are
also called as part of the port binding process, to determine whether
the associated mechanism can provide connectivity for the network, and
if so, the network segment and VIF driver to be used. The havana
release includes mechanism drivers for the Open vSwitch, Linux bridge,
and Hyper-V L2 agents, and for vendor switches/controllers/etc.
It also includes an L2 Population mechanism driver that
can help optimize tunneled virtual network traffic.

For additional information regarding the ML2 plugin and its collection
of type and mechanism drivers, see the OpenStack manuals and
http://wiki.openstack.org/wiki/Neutron/ML2.