Bug 2077681

This bug is to track Neutron OVN driver side of the implementation for qos min bandwidth limit API support.

+++ This bug was initially created as a clone of Bug #2060310 +++

The goal of this RFE is to add QoS minimum bandwidth guarantee rule support in core OVN. This new functionality should close the parity gap between Neutron ML2/OVS and ML2/OVN.

The scope of this RFE is limited to ports connected to physical networks (flat, VLAN); that means, VM ports that will egress traffic through a physical bridge.


Neutron ML2/OVS
===============
Now in ML2/OVS we provide minimum bandwidth only for those ports connected to physical networks (flat, VLAN). The QoS min-BW rules for a VM port are set in the physical bridge port where the VM port traffic leaves the node. The rationale for this is that the min-BW rules pretend to guarantee a certain BW for the VM traffic where the traffic is aggregated; this is in the physical port interface. [1] is the ML2/OVS implementation.

In ML2/OVS, the physical bridge interface port has a QoS register associated. This QoS register has several Queue registers, one per VM port. Each Queue register has a specific "queue-num" associated and the corresponding "other-config:min-rate" value.


Proposal
========
This RFE proposes to add a new parameter in DB NB "QoS.bandwdth" enumerate: ["rate", "burst", "minimum"]. The "match", "direction" and "priority" columns should work as now. In order to identify the egress port (physical bridge port), this RFE proposed to add a reference in "external_ids" (this is just an idea that could wrong due to my lack of knowledge in OVN internals).


Please, for more information you can reach me in IRC (ralonsoh), mail and this BZ.

Regards and thank you in advance.

[1]https://github.com/openstack/neutron/blob/b072cbf05f079519e379b2bfebe27846ae612275/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L179-L190

--- Additional comment from Daniel Alvarez Sanchez on 2022-03-03 15:07:21 UTC ---

One important note is that, at the moment OVN is implementing QoS via netdev [0] and not using OVS meters when the parameters are applied to the LSP.options column [1] (instead of to the QoS table).

If we want HW offload, since OVS meters are not yet supported we could take a similar approach using either netdev/iproute to allow for HW offload?


[0] https://github.com/ovn-org/ovn/blob/5f7a985de0707539e4df1eab4c4150b24dbce622/controller/binding.c#L221
[1] https://github.com/ovn-org/ovn/blob/b988d5fa62d9dbecacb2c45defab8e7edde4c533/ovn-nb.xml#L1031-L1039

--- Additional comment from Ihar Hrachyshka on 2022-04-20 12:20:35 UTC ---

(In reply to Daniel Alvarez Sanchez from comment #1)
> One important note is that, at the moment OVN is implementing QoS via netdev
> [0] and not using OVS meters when the parameters are applied to the
> LSP.options column [1] (instead of to the QoS table).
> 
> If we want HW offload, since OVS meters are not yet supported we could take
> a similar approach using either netdev/iproute to allow for HW offload?
> 
> 
> [0]
> https://github.com/ovn-org/ovn/blob/5f7a985de0707539e4df1eab4c4150b24dbce622/
> controller/binding.c#L221
> [1]
> https://github.com/ovn-org/ovn/blob/b988d5fa62d9dbecacb2c45defab8e7edde4c533/
> ovn-nb.xml#L1031-L1039

This series should give us hw offload for ovs metering: https://patchwork.ozlabs.org/project/openvswitch/list/?series=293970