Reviewed: https://review.opendev.org/c/openstack/neutron/+/819900 Committed: https://opendev.org/openstack/neutron/commit/ef7f673098c2a4574365f6f4ed20734f29309f08 Submitter: "Zuul (22348)" Branch: master
commit ef7f673098c2a4574365f6f4ed20734f29309f08 Author: Rodolfo Alonso Hernandez <[email protected]> Date: Tue Nov 30 16:01:27 2021 +0000 Do no use "--strict" for OF deletion in TRANSIENT_TABLE There are two types of OF rules in TRANSIENT_TABLE: - With priority 100: these rules match by "in_port", that is a unique identifier. - With priority 90: these rules match by MAC address and VLAN ID. This combination (MAC, VLAN) is unique. That means when a deleting an OF rule in TRANSIENT_TABLE, it is enough to specify the "in_port" or the (MAC, VLAN) tuple. The "--strict" parameter, added to also define the priority, is not needed. By removing the "--strict" parameter, these deletion commands can be executed synchronously at the end of the OVS deferred context, when all the OF rule commands (addition or deletion), are executed at the same time. That removes the small window, detected in the related bug, when the OF rule set for a port is not complete. Closes-Bug: #1952770 Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1952770 Title: [OVS][FW] Do not delete flows with "--strict" parameter in the OVS FW Status in neutron: Fix Released Bug description: The "--strict" parameter during the OF deletion was introduced to be able to define the parameter "priority" in the flow filter. Without " --strict" is not possible to filter by "priority". E.g.: [root@compute-0 ~]# ovs-ofctl del-flows br-int priority=100,table=60,in_port=144 # error ovs-ofctl: unknown keyword priority [root@compute-0 ~]# ovs-ofctl del-flows --strict br-int priority=100,table=60,in_port=144 # ok With deferred OF application (that means all flows are written/deleted at the same time, at the end of the deferred context), these strict flow deletion commands are executed before anything else. In some cases we have seen this small window can affect to some kind of traffic. For example UDP traffic is disrupted, the UDP packets arrive to the destination disordered. That could affect some applications. Further considerations: with trunk ports, as printed in [1], we can see that each subport has its own port ID (for rules with priority 100) and each own VLAN+MAC (for rules with priority 90). [1]https://paste.opendev.org/show/811353/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1952770/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
