Comment 0 for bug 1998608
Revision history for this message
| Rodolfo Alonso (rodolfo-alonso-hernandez) wrote | #0 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
The OVN architecture allows to avoid spawning compute agents like L3, DHCP or the specific ML2 agent (OVS, SRIOV, etc). This is because the local OVS service is configured by the local ovn-controller running on each node. This ovn-controller reads from the OVN SB database and executed the needed changes in the local OVS database and OF tables.
However that removes the ability of Neutron to directly interact with each compute node. For example, in [1][2] I proposed a POC of how to implement the ML2/OVS QoS extension for HW offloaded ports. With the current driver implementations, the HW offloaded ports do not apply the QoS rules on the VF of the port representors. That means we have a parity gap between virtio ports and HWOL ports.
While with ML2/OVS this gap can be closed with [1][2] as a workaround, in ML2/OVN this is not feasible. This RFE proposed to implement an OVN monitor agent that will run on each compute node, **if needed**, that will implement generic features/
The first feature to be implemented is the QoS extension for the port representor ports; in particular egress bandwidth limit rules and egress minimum bandwidth rules.
[1]https:/
[2]https:/