> > > > This patch reserves the ofport port number for the duration the ofport > > entry persists in the ovsdb. Once the entry is deleted from ovsdb the > > ofport number is recirculated on LRU basis. > > > > Signed-off-by: Vishal Deep Ajmera <[email protected]> > > This is an interesting patch and I like the idea. The implementation does add > some conceptual complexity. > > Can you say some more about the scenario that this covers? It isn't one that > I've > heard come up very much in the past. Does it arise in real situations that > you've > encountered?
Hi Ben, Thanks for looking into this patch. We have 2 scenarios in our deployment where we encountered issue. Scenario 1: (SDN Controller - ODL, OpenStack - Pike) Assume we have 4 ports in ovs on "netdev" bridge br-int: tap0 (1) tap1 (2) vhu1 (3) vhu2 (4) () denotes the ofport number allocated to the port by OVS. If the host compute is rebooted, the tap devices tap0 and tap1 are not recreated (or atleast not immediately). When OVS restarts the corresponding tap interfaces are in error state: "could not open network device tap0 (No such device)". Unfortunately due to this error, OVS sets the ofport field to -1 in OVSDB which means these ofport numbers (1) and (2) are now available to be allocated to any new port. At this time, SDN controller will need to remove all the flows pertaining to tap ports as ofport numbers are no longer same. A peculiar behavior we observed with OpenStack Pike was that when compute was restarted, it also triggered deletes and adds of all VHU ports (and not as a single transaction). This also resulted in change of existing vhu's ofport number. After compute reboot: tap0 (-1) -> "could not open network device tap0 (No such device)" tap1 (-1) -> "could not open network device tap1 (No such device)" vhu1 (3) vhu2 (4) Then a delete/add of vhu port changes the ofport allocation as follows: tap0 (-1) tap1 (-1) vhu1 (1) vhu2 (2) Things got messed up here as SDN controller on one hand trying to remove flows for tap0 /tap1 and on the other also modifying flows for vhu1 and vhu2. Unfortunately both tap0 and vhu1 has ofport (1) and tap1 and vhu2 has ofport (2). Until the time flows are properly cleaned by SDN controller we end up in stale flows of tap ports being used for vhu ports. If OVS avoids giving same ofport number (1) and (2) to existing VHU ports or any new port, this situation could be avoided. Scenario 2: (SDN Controller - ODL, OpenStack - Pike) We have another scenario in our deployment, where in we always start OVS with DPDK enabled. But if DPDK initialization fails due to any error, we fall back to non-dpdk mode and start OVS. This is to make sure we still manage to have connectivity with the computes. But this causes all VHU's and DPDK ports to fail and frees up their ofport numbers. Once we correct the underlying DPDK issue and start OVS again with dpdk mode, SDN controller is now required to reconstruct (and not just replay) all the flows which it had earlier as the ofport numbers are not guaranteed to be same again. This patch fixes both the above issue by retaining the ofport number till ofport entry exists in the OVSDB. Warm Regards, Vishal Ajmera _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
