UPD: I've posted a tiny series that implements (1) for your consideration here:
https://patchwork.ozlabs.org/project/ovn/list/?series=297048 It would be great if this can be backported to LTS. Seems like a low risk featurette. Thanks, Ihar On Mon, Apr 25, 2022 at 8:56 PM Ihar Hrachyshka <ihrac...@redhat.com> wrote: > > Hi all, > > I am working on the following feature request: > https://bugzilla.redhat.com/show_bug.cgi?id=2060310 > > Request is to maintain neutron OVN driver parity with the legacy > ml2/ovs driver. This means the feature is requested only for ports > attached to VLAN / flat networks (meaning, there's a physical bridge > to set QoS queues on). > > Existing neutron QoS API is working on port level: > https://docs.openstack.org/api-ref/network/v2/index.html#qos-bandwidth-limit-rules > > Existing OVN qos API is available in two flavors: > 1) LSP:options: > https://github.com/ovn-org/ovn/blob/b22684d4e37c3dd205a959925b6e3f1827bbe045/ovn-nb.xml#L1031-L1039 > 2) LS:qos_rules: > https://github.com/ovn-org/ovn/blob/b22684d4e37c3dd205a959925b6e3f1827bbe045/ovn-nb.xml#L470-L473 > > (1) is limited [relies on direct netdev commands on br-phys]. > (2) is more advanced [uses OVS meters, device agnostic]. > > Since ml2/ovs parity requires support for ports attached to a physical > port only, both approaches would work for OpenStack. > > In terms of hardware offload potential, (1) is ready, and (2) is not > offloaded yet. But, there is a OVS patch series up for review that > should allow it: > https://patchwork.ozlabs.org/project/openvswitch/list/?series=293970 > > Existing ml2/ovs implementation is very similar to what OVN already > does for LSP:options:qos_* settings: > https://github.com/openstack/neutron/blob/720a1c3de9a557478ed93d591f07276ae8df21f3/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L165-L198 > > For reference, OVN implementation can be found here: > https://github.com/ovn-org/ovn/blob/a0ded8874865d999ac9e8204c6affa4a5fd70699/controller/binding.c#L168 > > (1) can be well isolated in OVN. (2) will require implementation of > min bw guarantee in OVS first, then adopting the new meter config in > OVN. > > Considering that the next OVS release (2.18) is scheduled for Aug 2022 > and won't be LTS, I am not sure if we can rely on meters being > offloaded in the near future. Also, we would probably have to postpone > OVN implementation until the new meter is released in OVS, which means > skipping the next OVN release in June and including minimum bandwidth > guarantees in 22.09.0+. > > We in the Red Hat OpenStack team would like to speed up the delivery > of the QoS feature. We don't need device agnostic / smart flow > matching for the feature since we are merely looking at parity > differences with the now obsolete ml2/ovs driver. Hence (1) satisfies > our needs. Plus we need hardware offload support, and this is at the > moment not supported for OVS meters. > > Question: with that in mind, can (1) be implemented in OVN? > > We are operating on a tight schedule for 22.06 so I would appreciate > it if this can be clarified quickly so we can post all the needed > patches before soft freeze. > > Thanks, > Ihar _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
