Commit f5d916cb ("ovn-controller: Back out incremental processing")
left the conversion of the encaps module to a future patch set.
This patch converts this module back to full processing, but
does not remove all persistence of associated data strcutures.
This commit depends on f5d916cb ("ovn-controller:
Back out incremental processing").
Signed-off-by: Ryan Moats <rmo...@us.ibm.com>
---
ovn/controller/encaps.c | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/ovn/controller/encaps.c b/ovn/controller/encaps.c
index d99ba05..844447f 100644
--- a/ovn/controller/encaps.c
+++ b/ovn/controller/encaps.c
@@ -412,25 +412,21 @@ encaps_run(struct controller_ctx *ctx, const struct
ovsrec_bridge *br_int,
/* Maintain a mapping backwards from encap entries to their parent
* chassis. Most changes happen at the encap row entry but tunnels need
* to be established on the basis of the overall chassis. */
- SBREC_CHASSIS_FOR_EACH_TRACKED (chassis_rec, ctx->ovnsb_idl) {
- /* Defer deletion of mapping until we have cleaned up associated
- * ports. */
- if (!sbrec_chassis_is_deleted(chassis_rec)) {
- for (int i = 0; i < chassis_rec->n_encaps; i++) {
- encap_rec = chassis_rec->encaps[i];
-
- struct encap_hash_node *encap_hash_node;
- encap_hash_node = lookup_encap_uuid(&encap_rec->header_.uuid);
- if (encap_hash_node) {
- /* A change might have invalidated our mapping. Process the
- * new version and then iterate over everything to see if
it
- * is OK. */
- delete_encap_uuid(encap_hash_node);
- poll_immediate_wake();
- }
-
- insert_encap_uuid(&encap_rec->header_.uuid, chassis_rec);
+ SBREC_CHASSIS_FOR_EACH (chassis_rec, ctx->ovnsb_idl) {
+ for (int i = 0; i < chassis_rec->n_encaps; i++) {
+ encap_rec = chassis_rec->encaps[i];
+
+ struct encap_hash_node *encap_hash_node;
+ encap_hash_node = lookup_encap_uuid(&encap_rec->header_.uuid);
+ if (encap_hash_node) {
+ /* A change might have invalidated our mapping. Process the
+ * new version and then iterate over everything to see if it
+ * is OK. */
+ delete_encap_uuid(encap_hash_node);
+ poll_immediate_wake();
}
+
+ insert_encap_uuid(&encap_rec->header_.uuid, chassis_rec);
}
}
@@ -440,7 +436,7 @@ encaps_run(struct controller_ctx *ctx, const struct
ovsrec_bridge *br_int,
* might actually result in the creation of a different type tunnel if
* that type is preferred. That's OK - when we process the other encap
* rows, we'll just skip over the new tunnels. */
- SBREC_ENCAP_FOR_EACH_TRACKED (encap_rec, ctx->ovnsb_idl) {
+ SBREC_ENCAP_FOR_EACH (encap_rec, ctx->ovnsb_idl) {
struct encap_hash_node *encap_hash_node;
struct chassis_hash_node *chassis_hash_node;
const struct ovsrec_port *port_rec = NULL;
--
2.7.4
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
