2017-04-27 13:54:53 -07:00
|
|
|
|
/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 Nicira, Inc.
|
2017-08-03 14:20:15 -04:00
|
|
|
|
* Copyright (C) 2016 Hewlett Packard Enterprise Development LP
|
2009-12-02 11:26:15 -08:00
|
|
|
|
*
|
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
|
* You may obtain a copy of the License at:
|
|
|
|
|
*
|
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
*
|
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
|
* limitations under the License.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
|
|
|
|
|
#include "ovsdb-idl.h"
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
#include <errno.h>
|
2009-12-16 16:26:17 -08:00
|
|
|
|
#include <inttypes.h>
|
2009-12-02 11:26:15 -08:00
|
|
|
|
#include <limits.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
#include "bitmap.h"
|
2014-05-29 23:44:37 -07:00
|
|
|
|
#include "coverage.h"
|
2016-12-19 20:55:35 -08:00
|
|
|
|
#include "hash.h"
|
2016-03-03 10:20:46 -08:00
|
|
|
|
#include "openvswitch/dynamic-string.h"
|
2010-04-13 09:28:13 -07:00
|
|
|
|
#include "fatal-signal.h"
|
2016-07-12 16:37:34 -05:00
|
|
|
|
#include "openvswitch/json.h"
|
2009-12-02 11:26:15 -08:00
|
|
|
|
#include "jsonrpc.h"
|
2015-03-19 23:45:42 -07:00
|
|
|
|
#include "ovsdb/ovsdb.h"
|
|
|
|
|
#include "ovsdb/table.h"
|
2020-12-01 18:15:11 -08:00
|
|
|
|
#include "ovsdb-cs.h"
|
2009-12-02 11:26:15 -08:00
|
|
|
|
#include "ovsdb-data.h"
|
|
|
|
|
#include "ovsdb-error.h"
|
|
|
|
|
#include "ovsdb-idl-provider.h"
|
2015-03-19 23:45:42 -07:00
|
|
|
|
#include "ovsdb-parser.h"
|
2017-12-31 21:15:58 -08:00
|
|
|
|
#include "ovsdb-server-idl.h"
|
|
|
|
|
#include "ovsdb-session.h"
|
2017-11-03 13:53:53 +08:00
|
|
|
|
#include "openvswitch/poll-loop.h"
|
2016-07-12 16:37:34 -05:00
|
|
|
|
#include "openvswitch/shash.h"
|
2017-08-03 14:20:15 -04:00
|
|
|
|
#include "skiplist.h"
|
2015-03-19 23:45:42 -07:00
|
|
|
|
#include "sset.h"
|
2017-12-31 21:15:58 -08:00
|
|
|
|
#include "svec.h"
|
2009-12-02 11:26:15 -08:00
|
|
|
|
#include "util.h"
|
2017-08-03 14:20:15 -04:00
|
|
|
|
#include "uuid.h"
|
2014-12-15 14:10:38 +01:00
|
|
|
|
#include "openvswitch/vlog.h"
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2010-10-19 14:47:01 -07:00
|
|
|
|
VLOG_DEFINE_THIS_MODULE(ovsdb_idl);
|
2010-07-16 11:02:49 -07:00
|
|
|
|
|
2014-05-29 23:44:37 -07:00
|
|
|
|
COVERAGE_DEFINE(txn_uncommitted);
|
|
|
|
|
COVERAGE_DEFINE(txn_unchanged);
|
|
|
|
|
COVERAGE_DEFINE(txn_incomplete);
|
|
|
|
|
COVERAGE_DEFINE(txn_aborted);
|
|
|
|
|
COVERAGE_DEFINE(txn_success);
|
|
|
|
|
COVERAGE_DEFINE(txn_try_again);
|
|
|
|
|
COVERAGE_DEFINE(txn_not_locked);
|
|
|
|
|
COVERAGE_DEFINE(txn_error);
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
/* An arc from one idl_row to another. When row A contains a UUID that
|
|
|
|
|
* references row B, this is represented by an arc from A (the source) to B
|
|
|
|
|
* (the destination).
|
|
|
|
|
*
|
|
|
|
|
* Arcs from a row to itself are omitted, that is, src and dst are always
|
|
|
|
|
* different.
|
|
|
|
|
*
|
|
|
|
|
* Arcs are never duplicated, that is, even if there are multiple references
|
|
|
|
|
* from A to B, there is only a single arc from A to B.
|
|
|
|
|
*
|
|
|
|
|
* Arcs are directed: an arc from A to B is the converse of an an arc from B to
|
|
|
|
|
* A. Both an arc and its converse may both be present, if each row refers
|
|
|
|
|
* to the other circularly.
|
|
|
|
|
*
|
|
|
|
|
* The source and destination row may be in the same table or in different
|
|
|
|
|
* tables.
|
|
|
|
|
*/
|
|
|
|
|
struct ovsdb_idl_arc {
|
2014-12-15 14:10:38 +01:00
|
|
|
|
struct ovs_list src_node; /* In src->src_arcs list. */
|
|
|
|
|
struct ovs_list dst_node; /* In dst->dst_arcs list. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_row *src; /* Source row. */
|
|
|
|
|
struct ovsdb_idl_row *dst; /* Destination row. */
|
|
|
|
|
};
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovsdb_idl {
|
|
|
|
|
struct ovsdb_cs *cs;
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_class *class_;
|
2016-08-28 23:21:40 -07:00
|
|
|
|
struct shash table_by_name; /* Contains "struct ovsdb_idl_table *"s.*/
|
2017-08-11 11:06:44 -07:00
|
|
|
|
struct ovsdb_idl_table *tables; /* Array of ->class_->n_tables elements. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
unsigned int change_seqno;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_txn *txn;
|
|
|
|
|
struct hmap outstanding_txns;
|
|
|
|
|
bool verify_write_only;
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
struct ovs_list deleted_untracked_rows; /* Stores rows deleted in the
|
|
|
|
|
* current run, that are not yet
|
|
|
|
|
* added to the track_list. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
};
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
static struct ovsdb_cs_ops ovsdb_idl_cs_ops;
|
2017-12-31 21:15:58 -08:00
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
struct ovsdb_idl_txn {
|
|
|
|
|
struct hmap_node hmap_node;
|
|
|
|
|
struct json *request_id;
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovsdb_idl *idl;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
struct hmap txn_rows;
|
|
|
|
|
enum ovsdb_idl_txn_status status;
|
2010-02-05 14:11:12 -08:00
|
|
|
|
char *error;
|
2009-12-11 11:28:36 -08:00
|
|
|
|
bool dry_run;
|
2009-12-16 13:30:53 -08:00
|
|
|
|
struct ds comment;
|
2009-12-16 16:26:17 -08:00
|
|
|
|
|
|
|
|
|
/* Increments. */
|
2012-04-12 08:25:10 -07:00
|
|
|
|
const char *inc_table;
|
|
|
|
|
const char *inc_column;
|
|
|
|
|
struct uuid inc_row;
|
2016-08-07 20:44:51 -07:00
|
|
|
|
bool inc_force;
|
2009-12-16 16:26:17 -08:00
|
|
|
|
unsigned int inc_index;
|
|
|
|
|
int64_t inc_new_value;
|
2010-01-28 13:23:30 -08:00
|
|
|
|
|
|
|
|
|
/* Inserted rows. */
|
2011-09-15 12:53:12 -07:00
|
|
|
|
struct hmap inserted_rows; /* Contains "struct ovsdb_idl_txn_insert"s. */
|
2010-01-28 13:23:30 -08:00
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_txn_insert {
|
|
|
|
|
struct hmap_node hmap_node; /* In struct ovsdb_idl_txn's inserted_rows. */
|
|
|
|
|
struct uuid dummy; /* Dummy UUID used locally. */
|
|
|
|
|
int op_index; /* Index into transaction's operation array. */
|
|
|
|
|
struct uuid real; /* Real UUID used by database server. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct vlog_rate_limit syntax_rl = VLOG_RATE_LIMIT_INIT(1, 5);
|
|
|
|
|
static struct vlog_rate_limit semantic_rl = VLOG_RATE_LIMIT_INIT(1, 5);
|
2017-05-31 19:04:32 -04:00
|
|
|
|
static struct vlog_rate_limit other_rl = VLOG_RATE_LIMIT_INIT(1, 5);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2020-07-02 16:20:57 +02:00
|
|
|
|
enum update_result {
|
|
|
|
|
OVSDB_IDL_UPDATE_DB_CHANGED,
|
|
|
|
|
OVSDB_IDL_UPDATE_NO_CHANGES,
|
|
|
|
|
OVSDB_IDL_UPDATE_INCONSISTENT,
|
|
|
|
|
};
|
2020-11-21 11:47:01 -08:00
|
|
|
|
static void ovsdb_idl_clear(struct ovsdb_idl *);
|
2020-12-01 18:15:11 -08:00
|
|
|
|
static enum update_result ovsdb_idl_process_update(
|
|
|
|
|
struct ovsdb_idl_table *, const struct ovsdb_cs_row_update *);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
static void ovsdb_idl_insert_row(struct ovsdb_idl_row *,
|
|
|
|
|
const struct shash *values);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static void ovsdb_idl_delete_row(struct ovsdb_idl_row *);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
static bool ovsdb_idl_modify_row(struct ovsdb_idl_row *,
|
|
|
|
|
const struct shash *values, bool xor);
|
|
|
|
|
static void ovsdb_idl_parse_update(struct ovsdb_idl *,
|
|
|
|
|
const struct ovsdb_cs_update_event *);
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
static void ovsdb_idl_reparse_deleted(struct ovsdb_idl *);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
|
|
|
|
|
static void ovsdb_idl_txn_process_reply(struct ovsdb_idl *,
|
|
|
|
|
const struct jsonrpc_msg *);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
|
|
|
|
static bool ovsdb_idl_row_is_orphan(const struct ovsdb_idl_row *);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static struct ovsdb_idl_row *ovsdb_idl_row_create__(
|
|
|
|
|
const struct ovsdb_idl_table_class *);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static struct ovsdb_idl_row *ovsdb_idl_row_create(struct ovsdb_idl_table *,
|
|
|
|
|
const struct uuid *);
|
|
|
|
|
static void ovsdb_idl_row_destroy(struct ovsdb_idl_row *);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
static void ovsdb_idl_row_destroy_postprocess(struct ovsdb_idl *);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
static void ovsdb_idl_destroy_all_map_op_lists(struct ovsdb_idl_row *);
|
2016-08-06 17:46:29 -05:00
|
|
|
|
static void ovsdb_idl_destroy_all_set_op_lists(struct ovsdb_idl_row *);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2010-01-25 10:15:17 -08:00
|
|
|
|
static void ovsdb_idl_row_parse(struct ovsdb_idl_row *);
|
|
|
|
|
static void ovsdb_idl_row_unparse(struct ovsdb_idl_row *);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static void ovsdb_idl_row_clear_old(struct ovsdb_idl_row *);
|
|
|
|
|
static void ovsdb_idl_row_clear_new(struct ovsdb_idl_row *);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
static void ovsdb_idl_row_clear_arcs(struct ovsdb_idl_row *, bool destroy_dsts);
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
static void ovsdb_idl_row_reparse_backrefs(struct ovsdb_idl_row *);
|
|
|
|
|
static void ovsdb_idl_row_track_change(struct ovsdb_idl_row *,
|
|
|
|
|
enum ovsdb_idl_change);
|
|
|
|
|
static void ovsdb_idl_row_untrack_change(struct ovsdb_idl_row *);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
|
|
|
|
static void ovsdb_idl_txn_abort_all(struct ovsdb_idl *);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
static bool ovsdb_idl_txn_extract_mutations(struct ovsdb_idl_row *,
|
|
|
|
|
struct json *);
|
|
|
|
|
static void ovsdb_idl_txn_add_map_op(struct ovsdb_idl_row *,
|
|
|
|
|
const struct ovsdb_idl_column *,
|
|
|
|
|
struct ovsdb_datum *,
|
|
|
|
|
enum map_op_type);
|
2016-08-06 17:46:29 -05:00
|
|
|
|
static void ovsdb_idl_txn_add_set_op(struct ovsdb_idl_row *,
|
|
|
|
|
const struct ovsdb_idl_column *,
|
|
|
|
|
struct ovsdb_datum *,
|
|
|
|
|
enum set_op_type);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static struct ovsdb_idl_table *
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_table_from_class(const struct ovsdb_idl *,
|
2017-12-15 10:59:36 -08:00
|
|
|
|
const struct ovsdb_idl_table_class *);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
static struct ovsdb_idl_table *
|
|
|
|
|
ovsdb_idl_table_from_class(const struct ovsdb_idl *,
|
|
|
|
|
const struct ovsdb_idl_table_class *);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
static void ovsdb_idl_track_clear__(struct ovsdb_idl *, bool flush_all);
|
2011-07-26 16:49:03 -07:00
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
static void ovsdb_idl_destroy_indexes(struct ovsdb_idl_table *);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
static void ovsdb_idl_add_to_indexes(const struct ovsdb_idl_row *);
|
|
|
|
|
static void ovsdb_idl_remove_from_indexes(const struct ovsdb_idl_row *);
|
2020-06-05 14:00:29 +05:30
|
|
|
|
static int ovsdb_idl_try_commit_loop_txn(struct ovsdb_idl_loop *loop,
|
|
|
|
|
bool *may_need_wakeup);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
|
2021-03-24 10:33:40 +01:00
|
|
|
|
static void add_tracked_change_for_references(struct ovsdb_idl_row *);
|
|
|
|
|
|
2010-06-23 10:13:39 -07:00
|
|
|
|
/* Creates and returns a connection to database 'remote', which should be in a
|
|
|
|
|
* form acceptable to jsonrpc_session_open(). The connection will maintain an
|
|
|
|
|
* in-memory replica of the remote database whose schema is described by
|
|
|
|
|
* 'class'. (Ordinarily 'class' is compiled from an OVSDB schema automatically
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* by ovsdb-idlc.)
|
|
|
|
|
*
|
2013-03-15 16:14:28 -07:00
|
|
|
|
* Passes 'retry' to jsonrpc_session_open(). See that function for
|
|
|
|
|
* documentation.
|
|
|
|
|
*
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* If 'monitor_everything_by_default' is true, then everything in the remote
|
|
|
|
|
* database will be replicated by default. ovsdb_idl_omit() and
|
|
|
|
|
* ovsdb_idl_omit_alert() may be used to selectively drop some columns from
|
|
|
|
|
* monitoring.
|
|
|
|
|
*
|
|
|
|
|
* If 'monitor_everything_by_default' is false, then no columns or tables will
|
|
|
|
|
* be replicated by default. ovsdb_idl_add_column() and ovsdb_idl_add_table()
|
|
|
|
|
* must be used to choose some columns or tables to replicate.
|
|
|
|
|
*/
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl *
|
2010-11-16 09:14:52 -08:00
|
|
|
|
ovsdb_idl_create(const char *remote, const struct ovsdb_idl_class *class,
|
2013-03-15 16:14:28 -07:00
|
|
|
|
bool monitor_everything_by_default, bool retry)
|
2018-06-18 11:36:49 -07:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl *idl = ovsdb_idl_create_unconnected(
|
|
|
|
|
class, monitor_everything_by_default);
|
|
|
|
|
ovsdb_idl_set_remote(idl, remote, retry);
|
|
|
|
|
return idl;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Creates and returns a connection to an in-memory replica of the remote
|
|
|
|
|
* database whose schema is described by 'class'. (Ordinarily 'class' is
|
|
|
|
|
* compiled from an OVSDB schema automatically by ovsdb-idlc.)
|
|
|
|
|
*
|
|
|
|
|
* Use ovsdb_idl_set_remote() to configure the database to which to connect.
|
|
|
|
|
* Until a remote is configured, no data can be retrieved.
|
|
|
|
|
*
|
|
|
|
|
* If 'monitor_everything_by_default' is true, then everything in the remote
|
|
|
|
|
* database will be replicated by default. ovsdb_idl_omit() and
|
|
|
|
|
* ovsdb_idl_omit_alert() may be used to selectively drop some columns from
|
|
|
|
|
* monitoring.
|
|
|
|
|
*
|
|
|
|
|
* If 'monitor_everything_by_default' is false, then no columns or tables will
|
|
|
|
|
* be replicated by default. ovsdb_idl_add_column() and ovsdb_idl_add_table()
|
|
|
|
|
* must be used to choose some columns or tables to replicate.
|
|
|
|
|
*/
|
|
|
|
|
struct ovsdb_idl *
|
|
|
|
|
ovsdb_idl_create_unconnected(const struct ovsdb_idl_class *class,
|
|
|
|
|
bool monitor_everything_by_default)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovsdb_idl *idl = xmalloc(sizeof *idl);
|
|
|
|
|
*idl = (struct ovsdb_idl) {
|
|
|
|
|
.cs = ovsdb_cs_create(class->database, 3, &ovsdb_idl_cs_ops, idl),
|
|
|
|
|
.class_ = class,
|
|
|
|
|
.table_by_name = SHASH_INITIALIZER(&idl->table_by_name),
|
|
|
|
|
.tables = xmalloc(class->n_tables * sizeof *idl->tables),
|
|
|
|
|
.change_seqno = 0,
|
|
|
|
|
.txn = NULL,
|
|
|
|
|
.outstanding_txns = HMAP_INITIALIZER(&idl->outstanding_txns),
|
|
|
|
|
.verify_write_only = false,
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
.deleted_untracked_rows
|
|
|
|
|
= OVS_LIST_INITIALIZER(&idl->deleted_untracked_rows),
|
2020-11-21 11:47:01 -08:00
|
|
|
|
};
|
2010-11-16 09:14:52 -08:00
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
uint8_t default_mode = (monitor_everything_by_default
|
|
|
|
|
? OVSDB_IDL_MONITOR | OVSDB_IDL_ALERT
|
|
|
|
|
: 0);
|
|
|
|
|
for (size_t i = 0; i < class->n_tables; i++) {
|
|
|
|
|
const struct ovsdb_idl_table_class *tc = &class->tables[i];
|
|
|
|
|
struct ovsdb_idl_table *table = &idl->tables[i];
|
2017-12-31 21:15:58 -08:00
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
shash_add_assert(&idl->table_by_name, tc->name, table);
|
|
|
|
|
table->class_ = tc;
|
|
|
|
|
table->modes = xmalloc(tc->n_columns);
|
|
|
|
|
memset(table->modes, default_mode, tc->n_columns);
|
|
|
|
|
table->need_table = false;
|
|
|
|
|
shash_init(&table->columns);
|
|
|
|
|
ovs_list_init(&table->indexes);
|
|
|
|
|
for (size_t j = 0; j < tc->n_columns; j++) {
|
|
|
|
|
const struct ovsdb_idl_column *column = &tc->columns[j];
|
|
|
|
|
|
|
|
|
|
shash_add_assert(&table->columns, column->name, column);
|
|
|
|
|
}
|
|
|
|
|
hmap_init(&table->rows);
|
|
|
|
|
ovs_list_init(&table->track_list);
|
|
|
|
|
table->change_seqno[OVSDB_IDL_CHANGE_INSERT]
|
|
|
|
|
= table->change_seqno[OVSDB_IDL_CHANGE_MODIFY]
|
|
|
|
|
= table->change_seqno[OVSDB_IDL_CHANGE_DELETE] = 0;
|
|
|
|
|
table->idl = idl;
|
2021-08-26 18:56:13 -04:00
|
|
|
|
table->in_server_schema = false;
|
|
|
|
|
sset_init(&table->schema_columns);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
|
|
|
|
return idl;
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-18 11:36:49 -07:00
|
|
|
|
/* Changes the remote and creates a new session.
|
|
|
|
|
*
|
|
|
|
|
* If 'retry' is true, the connection to the remote will automatically retry
|
|
|
|
|
* when it fails. If 'retry' is false, the connection is one-time. */
|
2016-04-12 08:43:59 -05:00
|
|
|
|
void
|
2018-06-18 11:36:49 -07:00
|
|
|
|
ovsdb_idl_set_remote(struct ovsdb_idl *idl, const char *remote, bool retry)
|
2016-04-12 08:43:59 -05:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_set_remote(idl->cs, remote, retry);
|
2016-04-12 08:43:59 -05:00
|
|
|
|
}
|
|
|
|
|
|
2019-04-12 16:26:24 -07:00
|
|
|
|
/* Set whether the order of remotes should be shuffled, when there
|
|
|
|
|
* are more than one remotes. The setting doesn't take effect
|
|
|
|
|
* until the next time when ovsdb_idl_set_remote() is called. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_set_shuffle_remotes(struct ovsdb_idl *idl, bool shuffle)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_set_shuffle_remotes(idl->cs, shuffle);
|
2019-04-12 16:26:24 -07:00
|
|
|
|
}
|
|
|
|
|
|
2020-05-01 15:13:08 -04:00
|
|
|
|
/* Reset min_index to 0. This prevents a situation where the client
|
|
|
|
|
* thinks all databases have stale data, when they actually have all
|
|
|
|
|
* been destroyed and rebuilt from scratch.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_reset_min_index(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_reset_min_index(idl->cs);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-06-23 10:13:39 -07:00
|
|
|
|
/* Destroys 'idl' and all of the data structures that it manages. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_destroy(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
if (idl) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovs_assert(!idl->txn);
|
|
|
|
|
|
|
|
|
|
ovsdb_idl_txn_abort_all(idl);
|
|
|
|
|
hmap_destroy(&idl->outstanding_txns);
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_clear(idl);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_destroy(idl->cs);
|
|
|
|
|
for (size_t i = 0; i < idl->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &idl->tables[i];
|
|
|
|
|
ovsdb_idl_destroy_indexes(table);
|
|
|
|
|
shash_destroy(&table->columns);
|
2021-08-26 18:56:13 -04:00
|
|
|
|
sset_destroy(&table->schema_columns);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
hmap_destroy(&table->rows);
|
|
|
|
|
free(table->modes);
|
|
|
|
|
}
|
|
|
|
|
shash_destroy(&idl->table_by_name);
|
|
|
|
|
free(idl->tables);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
free(idl);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-01 16:58:24 -08:00
|
|
|
|
/* By default, or if 'leader_only' is true, when 'idl' connects to a clustered
|
|
|
|
|
* database, the IDL will avoid servers other than the cluster leader. This
|
|
|
|
|
* ensures that any data that it reads and reports is up-to-date. If
|
|
|
|
|
* 'leader_only' is false, the IDL will accept any server in the cluster, which
|
|
|
|
|
* means that for read-only transactions it can report and act on stale data
|
|
|
|
|
* (transactions that modify the database are always serialized even with false
|
|
|
|
|
* 'leader_only'). Refer to Understanding Cluster Consistency in ovsdb(7) for
|
|
|
|
|
* more information. */
|
2017-12-31 21:15:58 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_set_leader_only(struct ovsdb_idl *idl, bool leader_only)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_set_leader_only(idl->cs, leader_only);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static void
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_clear(struct ovsdb_idl *db)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
/* Process deleted rows, removing them from the 'deleted_untracked_rows'
|
|
|
|
|
* list and reparsing their backrefs.
|
|
|
|
|
*/
|
|
|
|
|
ovsdb_idl_reparse_deleted(db);
|
|
|
|
|
|
|
|
|
|
/* Cleanup all rows; each row gets added to its own table's
|
|
|
|
|
* 'track_list'.
|
|
|
|
|
*/
|
2020-11-21 11:47:01 -08:00
|
|
|
|
for (size_t i = 0; i < db->class_->n_tables; i++) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_row *row, *next_row;
|
|
|
|
|
|
|
|
|
|
if (hmap_is_empty(&table->rows)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_SAFE (row, next_row, hmap_node, &table->rows) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_arc *arc, *next_arc;
|
|
|
|
|
|
|
|
|
|
if (!ovsdb_idl_row_is_orphan(row)) {
|
2017-08-03 14:20:15 -04:00
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2010-09-17 10:33:10 -07:00
|
|
|
|
LIST_FOR_EACH_SAFE (arc, next_arc, src_node, &row->src_arcs) {
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
ovs_list_remove(&arc->src_node);
|
|
|
|
|
ovs_list_remove(&arc->dst_node);
|
|
|
|
|
free(arc);
|
|
|
|
|
}
|
|
|
|
|
LIST_FOR_EACH_SAFE (arc, next_arc, dst_node, &row->dst_arcs) {
|
|
|
|
|
ovs_list_remove(&arc->src_node);
|
|
|
|
|
ovs_list_remove(&arc->dst_node);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
free(arc);
|
|
|
|
|
}
|
|
|
|
|
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_destroy(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
|
|
|
|
|
/* Free rows deleted from tables with change tracking disabled. */
|
2019-03-05 18:16:50 -08:00
|
|
|
|
ovsdb_idl_row_destroy_postprocess(db);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
/* Free rows deleted from tables with change tracking enabled. */
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_track_clear__(db, true);
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
ovs_assert(ovs_list_is_empty(&db->deleted_untracked_rows));
|
2020-11-21 11:47:01 -08:00
|
|
|
|
db->change_seqno++;
|
2017-12-31 21:15:58 -08:00
|
|
|
|
}
|
|
|
|
|
|
2012-03-27 10:16:52 -07:00
|
|
|
|
/* Processes a batch of messages from the database server on 'idl'. This may
|
|
|
|
|
* cause the IDL's contents to change. The client may check for that with
|
|
|
|
|
* ovsdb_idl_get_seqno(). */
|
|
|
|
|
void
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_run(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovs_assert(!idl->txn);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovs_list events;
|
|
|
|
|
ovsdb_cs_run(idl->cs, &events);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovsdb_cs_event *event;
|
|
|
|
|
LIST_FOR_EACH_POP (event, list_node, &events) {
|
|
|
|
|
switch (event->type) {
|
|
|
|
|
case OVSDB_CS_EVENT_TYPE_RECONNECT:
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_txn_abort_all(idl);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
break;
|
2015-03-19 23:45:42 -07:00
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
case OVSDB_CS_EVENT_TYPE_LOCKED:
|
ovsdb-idl: Fix the database update signaling if it has never been connected.
The symptom of this issue is that OVS bridge looses its IP address on
restart.
Simple reproducer:
0. start ovsdb-server and ovs-vswitchd
1. ovs-vsctl add-br br0
2. ifconfig br0 10.0.0.1 up
3. ovs-appctl -t ovs-vswitchd exit
4. start ovs-vswitchd back.
After step #3 ovs-vswitchd is down, but br0 interface exists and
has configured IP address. After step #4 there is no IP address
on the port br0.
What happened:
1. ovsdb-cs connects to the database via ovsdb-idl and requests
database lock.
--> get_schema for _Server database
--> lock request
2. ovsdb-cs receives schema for the _Server database. And sends
monitor request.
<-- schema for _Server
--> monitor_cond for _Server
3. ovsdb-cs receives lock reply.
<-- locked
At this point ovsdb-cs generates OVSDB_CS_EVENT_TYPE_LOCKED
event and passes it to ovsdb-idl. ovsdb-idl increases change_seqno.
4. ovsdb_idl_has_ever_connected() is 'true' now, because change_seqno
is not zero.
5. ovs-vswitchd decides that it has connection with database and
all the initial data, therefore initiates configuration of bridges.
bridge_run():ovsdb_idl_has_ever_connected() --> true
6. Since monitor request for the Open_vSwitch database is not even
sent yet, the database is empty. This leads to removal of all the
ports and all other resources.
7. When data finally received, ovs-vswitchd re-creates bridges and
ports, but IP addresses can not be restored.
While splitting out ovsdb-cs from ovsdb-idl one part of the logic
was lost. Particularly, before the split, ovsdb-idl updated
change_seqno only in MONITORING state.
Restoring the logic by updating the change_seqno only if may send
transaction, i.e. lock is ours and ovsdb-cs is in the MONITORING
state. This matches with the main purpose of increasing change_seqno
at this point, i.e. to force the client to re-try the transaction.
With this change ovsdb_idl_has_ever_connected() remains 'false'
until the first monitor reply with the actual data received.
This issue was reported several times during the last couple of weeks.
Reported-at: https://bugzilla.redhat.com/1968445
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383512.html
Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2021-June/051222.html
Fixes: 1c337c43ac1c ("ovsdb-idl: Break into two layers.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Dumitru Ceara <dceara@redhat.com>
2021-06-08 15:17:23 +02:00
|
|
|
|
if (ovsdb_cs_may_send_transaction(idl->cs)) {
|
|
|
|
|
/* If the client couldn't run a transaction because it didn't
|
|
|
|
|
* have the lock, this will encourage it to try again. */
|
|
|
|
|
idl->change_seqno++;
|
|
|
|
|
} else {
|
|
|
|
|
/* We're setting up a session, so don't signal that the
|
|
|
|
|
* database changed. Finalizing the session will increment
|
|
|
|
|
* change_seqno anyhow. */
|
|
|
|
|
}
|
2020-11-21 11:47:01 -08:00
|
|
|
|
break;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
case OVSDB_CS_EVENT_TYPE_UPDATE:
|
|
|
|
|
ovsdb_idl_parse_update(idl, &event->update);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case OVSDB_CS_EVENT_TYPE_TXN_REPLY:
|
|
|
|
|
ovsdb_idl_txn_process_reply(idl, event->txn_reply);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
break;
|
|
|
|
|
}
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_event_destroy(event);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
ovsdb_idl_reparse_deleted(idl);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_row_destroy_postprocess(idl);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-06-23 10:13:39 -07:00
|
|
|
|
/* Arranges for poll_block() to wake up when ovsdb_idl_run() has something to
|
|
|
|
|
* do or when activity occurs on a transaction on 'idl'. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_wait(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_wait(idl->cs);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns a "sequence number" that represents the state of 'idl'. When
|
|
|
|
|
* ovsdb_idl_run() changes the database, the sequence number changes. The
|
|
|
|
|
* initial fetch of the entire contents of the remote database is considered to
|
|
|
|
|
* be one kind of change. Successfully acquiring a lock, if one has been
|
|
|
|
|
* configured with ovsdb_idl_set_lock(), is also considered to be a change.
|
|
|
|
|
*
|
|
|
|
|
* As long as the sequence number does not change, the client may continue to
|
|
|
|
|
* use any data structures it obtains from 'idl'. But when it changes, the
|
|
|
|
|
* client must not access any of these data structures again, because they
|
|
|
|
|
* could have freed or reused for other purposes.
|
|
|
|
|
*
|
|
|
|
|
* The sequence number can occasionally change even if the database does not.
|
|
|
|
|
* This happens if the connection to the database drops and reconnects, which
|
|
|
|
|
* causes the database contents to be reloaded even if they didn't change. (It
|
|
|
|
|
* could also happen if the database server sends out a "change" that reflects
|
|
|
|
|
* what the IDL already thought was in the database. The database server is
|
|
|
|
|
* not supposed to do that, but bugs could in theory cause it to do so.) */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
unsigned int
|
|
|
|
|
ovsdb_idl_get_seqno(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return idl->change_seqno;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2016-12-19 23:55:01 -08:00
|
|
|
|
/* Returns a "sequence number" that represents the number of conditional
|
|
|
|
|
* monitoring updates successfully received by the OVSDB server of an IDL
|
|
|
|
|
* connection.
|
|
|
|
|
*
|
|
|
|
|
* ovsdb_idl_set_condition() sets a new condition that is different from
|
|
|
|
|
* the current condtion, the next expected "sequence number" is returned.
|
|
|
|
|
*
|
|
|
|
|
* Whenever ovsdb_idl_get_cond_seqno() returns a value that matches
|
|
|
|
|
* the return value of ovsdb_idl_set_condition(), The client is
|
|
|
|
|
* assured that:
|
|
|
|
|
* - The ovsdb_idl_set_condition() changes has been acknowledged by
|
|
|
|
|
* the OVSDB sever.
|
|
|
|
|
*
|
|
|
|
|
* - 'idl' now contains the content matches the new conditions. */
|
|
|
|
|
unsigned int
|
|
|
|
|
ovsdb_idl_get_condition_seqno(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return ovsdb_cs_get_condition_seqno(idl->cs);
|
2016-12-19 23:55:01 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-06-23 10:13:39 -07:00
|
|
|
|
/* Returns true if 'idl' successfully connected to the remote database and
|
|
|
|
|
* retrieved its contents (even if the connection subsequently dropped and is
|
|
|
|
|
* in the process of reconnecting). If so, then 'idl' contains an atomic
|
|
|
|
|
* snapshot of the database's contents (but it might be arbitrarily old if the
|
|
|
|
|
* connection dropped).
|
|
|
|
|
*
|
|
|
|
|
* Returns false if 'idl' has never connected or retrieved the database's
|
|
|
|
|
* contents. If so, 'idl' is empty. */
|
2010-01-14 13:10:35 -08:00
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_has_ever_connected(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
return ovsdb_idl_get_seqno(idl) != 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-02-18 13:19:36 -08:00
|
|
|
|
/* Reconfigures 'idl' so that it would reconnect to the database, if
|
|
|
|
|
* connection was dropped. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_enable_reconnect(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_enable_reconnect(idl->cs);
|
2014-02-18 13:19:36 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-06-23 10:13:39 -07:00
|
|
|
|
/* Forces 'idl' to drop its connection to the database and reconnect. In the
|
|
|
|
|
* meantime, the contents of 'idl' will not change. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_force_reconnect(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_force_reconnect(idl->cs);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2012-09-20 11:13:15 -07:00
|
|
|
|
|
|
|
|
|
/* Some IDL users should only write to write-only columns. Furthermore,
|
|
|
|
|
* writing to a column which is not write-only can cause serious performance
|
|
|
|
|
* degradations for these users. This function causes 'idl' to reject writes
|
|
|
|
|
* to columns which are not marked write only using ovsdb_idl_omit_alert(). */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_verify_write_only(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
idl->verify_write_only = true;
|
2012-09-20 11:13:15 -07:00
|
|
|
|
}
|
2013-03-15 16:14:28 -07:00
|
|
|
|
|
2016-02-24 10:48:34 -05:00
|
|
|
|
/* Returns true if 'idl' is currently connected or trying to connect
|
|
|
|
|
* and a negative response to a schema request has not been received */
|
2013-03-15 16:14:28 -07:00
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_is_alive(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return ovsdb_cs_is_alive(idl->cs);
|
2013-03-15 16:14:28 -07:00
|
|
|
|
}
|
|
|
|
|
|
2018-07-31 17:35:00 +02:00
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_is_connected(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return ovsdb_cs_is_connected(idl->cs);
|
2018-07-31 17:35:00 +02:00
|
|
|
|
}
|
|
|
|
|
|
2015-03-31 11:28:39 -07:00
|
|
|
|
/* Returns the last error reported on a connection by 'idl'. The return value
|
2016-02-24 10:48:34 -05:00
|
|
|
|
* is 0 only if no connection made by 'idl' has ever encountered an error and
|
|
|
|
|
* a negative response to a schema request has never been received. See
|
|
|
|
|
* jsonrpc_get_status() for jsonrpc_session_get_last_error() return value
|
|
|
|
|
* interpretation. */
|
2013-03-15 16:14:28 -07:00
|
|
|
|
int
|
|
|
|
|
ovsdb_idl_get_last_error(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return ovsdb_cs_get_last_error(idl->cs);
|
2013-03-15 16:14:28 -07:00
|
|
|
|
}
|
2016-03-25 02:18:34 +08:00
|
|
|
|
|
|
|
|
|
/* Sets the "probe interval" for 'idl->session' to 'probe_interval', in
|
|
|
|
|
* milliseconds.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_set_probe_interval(const struct ovsdb_idl *idl, int probe_interval)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_set_probe_interval(idl->cs, probe_interval);
|
2016-03-25 02:18:34 +08:00
|
|
|
|
}
|
2016-09-07 09:04:46 -07:00
|
|
|
|
|
|
|
|
|
static size_t
|
|
|
|
|
find_uuid_in_array(const struct uuid *target,
|
|
|
|
|
const struct uuid *array, size_t n)
|
|
|
|
|
{
|
|
|
|
|
for (size_t i = 0; i < n; i++) {
|
|
|
|
|
if (uuid_equals(&array[i], target)) {
|
|
|
|
|
return i;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return SIZE_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static size_t
|
|
|
|
|
array_contains_uuid(const struct uuid *target,
|
|
|
|
|
const struct uuid *array, size_t n)
|
|
|
|
|
{
|
|
|
|
|
return find_uuid_in_array(target, array, n) != SIZE_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
remove_uuid_from_array(const struct uuid *target,
|
|
|
|
|
struct uuid *array, size_t *n)
|
|
|
|
|
{
|
|
|
|
|
size_t i = find_uuid_in_array(target, array, *n);
|
|
|
|
|
if (i != SIZE_MAX) {
|
|
|
|
|
array[i] = array[--*n];
|
|
|
|
|
return true;
|
|
|
|
|
} else {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
add_row_references(const struct ovsdb_base_type *type,
|
|
|
|
|
const union ovsdb_atom *atoms, size_t n_atoms,
|
|
|
|
|
const struct uuid *exclude_uuid,
|
|
|
|
|
struct uuid **dstsp, size_t *n_dstsp,
|
|
|
|
|
size_t *allocated_dstsp)
|
|
|
|
|
{
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (type->type != OVSDB_TYPE_UUID || !type->uuid.refTableName) {
|
2016-09-07 09:04:46 -07:00
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (size_t i = 0; i < n_atoms; i++) {
|
|
|
|
|
const struct uuid *uuid = &atoms[i].uuid;
|
|
|
|
|
if (!uuid_equals(uuid, exclude_uuid)
|
|
|
|
|
&& !array_contains_uuid(uuid, *dstsp, *n_dstsp)) {
|
|
|
|
|
if (*n_dstsp >= *allocated_dstsp) {
|
|
|
|
|
*dstsp = x2nrealloc(*dstsp, allocated_dstsp,
|
|
|
|
|
sizeof **dstsp);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
(*dstsp)[*n_dstsp] = *uuid;
|
|
|
|
|
++*n_dstsp;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Checks for consistency in 'idl''s graph of arcs between database rows. Each
|
|
|
|
|
* reference from one row to a different row should be reflected as a "struct
|
|
|
|
|
* ovsdb_idl_arc" between those rows.
|
|
|
|
|
*
|
|
|
|
|
* This function is slow, big-O wise, and aborts if it finds an inconsistency,
|
|
|
|
|
* thus it is only for use in test programs. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_check_consistency(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
/* Consistency is broken while a transaction is in progress. */
|
2020-11-21 11:47:01 -08:00
|
|
|
|
if (!idl->txn) {
|
2016-09-07 09:04:46 -07:00
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ok = true;
|
|
|
|
|
|
|
|
|
|
struct uuid *dsts = NULL;
|
|
|
|
|
size_t allocated_dsts = 0;
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
for (size_t i = 0; i < idl->class_->n_tables; i++) {
|
|
|
|
|
const struct ovsdb_idl_table *table = &idl->tables[i];
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = table->class_;
|
2016-09-07 09:04:46 -07:00
|
|
|
|
|
|
|
|
|
const struct ovsdb_idl_row *row;
|
|
|
|
|
HMAP_FOR_EACH (row, hmap_node, &table->rows) {
|
|
|
|
|
size_t n_dsts = 0;
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (row->new_datum) {
|
2016-09-07 09:04:46 -07:00
|
|
|
|
size_t n_columns = shash_count(&row->table->columns);
|
|
|
|
|
for (size_t j = 0; j < n_columns; j++) {
|
|
|
|
|
const struct ovsdb_type *type = &class->columns[j].type;
|
2017-08-11 11:06:46 -07:00
|
|
|
|
const struct ovsdb_datum *datum = &row->new_datum[j];
|
2016-09-07 09:04:46 -07:00
|
|
|
|
add_row_references(&type->key,
|
|
|
|
|
datum->keys, datum->n, &row->uuid,
|
|
|
|
|
&dsts, &n_dsts, &allocated_dsts);
|
|
|
|
|
add_row_references(&type->value,
|
|
|
|
|
datum->values, datum->n, &row->uuid,
|
|
|
|
|
&dsts, &n_dsts, &allocated_dsts);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
const struct ovsdb_idl_arc *arc;
|
|
|
|
|
LIST_FOR_EACH (arc, src_node, &row->src_arcs) {
|
|
|
|
|
if (!remove_uuid_from_array(&arc->dst->uuid,
|
|
|
|
|
dsts, &n_dsts)) {
|
|
|
|
|
VLOG_ERR("unexpected arc from %s row "UUID_FMT" to %s "
|
|
|
|
|
"row "UUID_FMT,
|
2017-08-11 11:06:44 -07:00
|
|
|
|
table->class_->name,
|
2016-09-07 09:04:46 -07:00
|
|
|
|
UUID_ARGS(&row->uuid),
|
2017-08-11 11:06:44 -07:00
|
|
|
|
arc->dst->table->class_->name,
|
2016-09-07 09:04:46 -07:00
|
|
|
|
UUID_ARGS(&arc->dst->uuid));
|
|
|
|
|
ok = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-08-02 15:03:06 -07:00
|
|
|
|
for (size_t j = 0; j < n_dsts; j++) {
|
2016-09-07 09:04:46 -07:00
|
|
|
|
VLOG_ERR("%s row "UUID_FMT" missing arc to row "UUID_FMT,
|
2017-08-11 11:06:44 -07:00
|
|
|
|
table->class_->name, UUID_ARGS(&row->uuid),
|
2017-08-02 15:03:06 -07:00
|
|
|
|
UUID_ARGS(&dsts[j]));
|
2016-09-07 09:04:46 -07:00
|
|
|
|
ok = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
free(dsts);
|
|
|
|
|
ovs_assert(ok);
|
|
|
|
|
}
|
2020-11-21 11:47:01 -08:00
|
|
|
|
|
|
|
|
|
static struct json *
|
|
|
|
|
ovsdb_idl_compose_monitor_request(const struct json *schema_json, void *idl_)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl *idl = idl_;
|
|
|
|
|
|
|
|
|
|
struct shash *schema = ovsdb_cs_parse_schema(schema_json);
|
|
|
|
|
struct json *monitor_requests = json_object_create();
|
|
|
|
|
|
|
|
|
|
for (size_t i = 0; i < idl->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &idl->tables[i];
|
|
|
|
|
const struct ovsdb_idl_table_class *tc = table->class_;
|
|
|
|
|
struct json *monitor_request;
|
|
|
|
|
const struct sset *table_schema
|
|
|
|
|
= schema ? shash_find_data(schema, table->class_->name) : NULL;
|
|
|
|
|
|
|
|
|
|
struct json *columns
|
|
|
|
|
= table->need_table ? json_array_create_empty() : NULL;
|
2021-08-26 18:56:13 -04:00
|
|
|
|
sset_clear(&table->schema_columns);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
for (size_t j = 0; j < tc->n_columns; j++) {
|
|
|
|
|
const struct ovsdb_idl_column *column = &tc->columns[j];
|
|
|
|
|
bool idl_has_column = (table_schema &&
|
|
|
|
|
sset_contains(table_schema, column->name));
|
2021-08-26 18:56:13 -04:00
|
|
|
|
|
|
|
|
|
if (idl_has_column) {
|
|
|
|
|
sset_add(&table->schema_columns, column->name);
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
if (column->is_synthetic) {
|
|
|
|
|
if (idl_has_column) {
|
|
|
|
|
VLOG_WARN("%s table in %s database has synthetic "
|
|
|
|
|
"column %s", table->class_->name,
|
|
|
|
|
idl->class_->database, column->name);
|
|
|
|
|
}
|
|
|
|
|
} else if (table->modes[j] & OVSDB_IDL_MONITOR) {
|
|
|
|
|
if (table_schema && !idl_has_column) {
|
|
|
|
|
VLOG_WARN("%s table in %s database lacks %s column "
|
|
|
|
|
"(database needs upgrade?)",
|
|
|
|
|
table->class_->name, idl->class_->database,
|
|
|
|
|
column->name);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
if (!columns) {
|
|
|
|
|
columns = json_array_create_empty();
|
|
|
|
|
}
|
|
|
|
|
json_array_add(columns, json_string_create(column->name));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (columns) {
|
|
|
|
|
if (schema && !table_schema) {
|
|
|
|
|
VLOG_WARN("%s database lacks %s table "
|
|
|
|
|
"(database needs upgrade?)",
|
|
|
|
|
idl->class_->database, table->class_->name);
|
|
|
|
|
json_destroy(columns);
|
2021-08-26 18:56:13 -04:00
|
|
|
|
table->in_server_schema = false;
|
2020-11-21 11:47:01 -08:00
|
|
|
|
continue;
|
2021-08-26 18:56:13 -04:00
|
|
|
|
} else if (schema && table_schema) {
|
|
|
|
|
table->in_server_schema = true;
|
2020-11-21 11:47:01 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
monitor_request = json_object_create();
|
|
|
|
|
json_object_put(monitor_request, "columns", columns);
|
|
|
|
|
json_object_put(monitor_requests, tc->name,
|
|
|
|
|
json_array_create_1(monitor_request));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ovsdb_cs_free_schema(schema);
|
|
|
|
|
|
|
|
|
|
return monitor_requests;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct ovsdb_cs_ops ovsdb_idl_cs_ops = {
|
|
|
|
|
ovsdb_idl_compose_monitor_request,
|
|
|
|
|
};
|
2010-11-16 09:14:52 -08:00
|
|
|
|
|
2017-04-27 13:54:53 -07:00
|
|
|
|
const struct ovsdb_idl_class *
|
|
|
|
|
ovsdb_idl_get_class(const struct ovsdb_idl *idl)
|
2010-08-11 15:41:41 -07:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return idl->class_;
|
2017-04-27 13:54:53 -07:00
|
|
|
|
}
|
2010-08-11 15:41:41 -07:00
|
|
|
|
|
2017-04-27 13:54:53 -07:00
|
|
|
|
/* Given 'column' in some table in 'class', returns the table's class. */
|
|
|
|
|
const struct ovsdb_idl_table_class *
|
|
|
|
|
ovsdb_idl_table_class_from_column(const struct ovsdb_idl_class *class,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
|
|
|
|
for (size_t i = 0; i < class->n_tables; i++) {
|
|
|
|
|
const struct ovsdb_idl_table_class *tc = &class->tables[i];
|
2010-08-11 15:41:41 -07:00
|
|
|
|
if (column >= tc->columns && column < &tc->columns[tc->n_columns]) {
|
2017-04-27 13:54:53 -07:00
|
|
|
|
return tc;
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-17 10:32:12 -08:00
|
|
|
|
OVS_NOT_REACHED();
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
/* Given 'column' in some table in 'idl', returns the table. */
|
2017-04-27 13:54:53 -07:00
|
|
|
|
static struct ovsdb_idl_table *
|
2021-08-26 18:56:13 -04:00
|
|
|
|
ovsdb_idl_table_from_column(const struct ovsdb_idl *idl,
|
2017-04-27 13:54:53 -07:00
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table_class *tc =
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_table_class_from_column(idl->class_, column);
|
|
|
|
|
return &idl->tables[tc - idl->class_->tables];
|
2017-04-27 13:54:53 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static unsigned char *
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_get_mode(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
2017-04-27 13:54:53 -07:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovs_assert(!idl->change_seqno);
|
2017-04-27 13:54:53 -07:00
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
const struct ovsdb_idl_table *table = ovsdb_idl_table_from_column(idl,
|
2017-04-27 13:54:53 -07:00
|
|
|
|
column);
|
2017-08-11 11:06:44 -07:00
|
|
|
|
return &table->modes[column - table->class_->columns];
|
2017-04-27 13:54:53 -07:00
|
|
|
|
}
|
|
|
|
|
|
2018-07-19 15:51:07 +02:00
|
|
|
|
static void
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_set_mode(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
unsigned char mode)
|
2018-07-19 15:51:07 +02:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
const struct ovsdb_idl_table *table = ovsdb_idl_table_from_column(idl,
|
2018-07-19 15:51:07 +02:00
|
|
|
|
column);
|
|
|
|
|
size_t column_idx = column - table->class_->columns;
|
|
|
|
|
|
|
|
|
|
if (table->modes[column_idx] != mode) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
*ovsdb_idl_get_mode(idl, column) = mode;
|
2018-07-19 15:51:07 +02:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-11-16 09:14:52 -08:00
|
|
|
|
static void
|
2020-11-21 11:47:01 -08:00
|
|
|
|
add_ref_table(struct ovsdb_idl *idl, const struct ovsdb_base_type *base)
|
2010-11-16 09:14:52 -08:00
|
|
|
|
{
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (base->type == OVSDB_TYPE_UUID && base->uuid.refTableName) {
|
2010-11-16 09:14:52 -08:00
|
|
|
|
struct ovsdb_idl_table *table;
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
table = shash_find_data(&idl->table_by_name, base->uuid.refTableName);
|
2010-11-16 09:14:52 -08:00
|
|
|
|
if (table) {
|
|
|
|
|
table->need_table = true;
|
|
|
|
|
} else {
|
|
|
|
|
VLOG_WARN("%s IDL class missing referenced table %s",
|
2020-11-21 11:47:01 -08:00
|
|
|
|
idl->class_->database, base->uuid.refTableName);
|
2010-11-16 09:14:52 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Turns on OVSDB_IDL_MONITOR and OVSDB_IDL_ALERT for 'column' in 'idl'. Also
|
|
|
|
|
* ensures that any tables referenced by 'column' will be replicated, even if
|
|
|
|
|
* no columns in that table are selected for replication (see
|
|
|
|
|
* ovsdb_idl_add_table() for more information).
|
2010-08-11 15:41:41 -07:00
|
|
|
|
*
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* This function is only useful if 'monitor_everything_by_default' was false in
|
|
|
|
|
* the call to ovsdb_idl_create(). This function should be called between
|
|
|
|
|
* ovsdb_idl_create() and the first call to ovsdb_idl_run().
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_add_column(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_set_mode(idl, column, OVSDB_IDL_MONITOR | OVSDB_IDL_ALERT);
|
|
|
|
|
add_ref_table(idl, &column->type.key);
|
|
|
|
|
add_ref_table(idl, &column->type.value);
|
2010-11-16 09:14:52 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Ensures that the table with class 'tc' will be replicated on 'idl' even if
|
2015-11-27 16:57:07 +00:00
|
|
|
|
* no columns are selected for replication. Just the necessary data for table
|
|
|
|
|
* references will be replicated (the UUID of the rows, for instance), any
|
|
|
|
|
* columns not selected for replication will remain unreplicated.
|
|
|
|
|
* This can be useful because it allows 'idl' to keep track of what rows in the
|
|
|
|
|
* table actually exist, which in turn allows columns that reference the table
|
|
|
|
|
* to have accurate contents. (The IDL presents the database with references to
|
|
|
|
|
* rows that do not exist removed.)
|
2010-08-11 15:41:41 -07:00
|
|
|
|
*
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* This function is only useful if 'monitor_everything_by_default' was false in
|
|
|
|
|
* the call to ovsdb_idl_create(). This function should be called between
|
|
|
|
|
* ovsdb_idl_create() and the first call to ovsdb_idl_run().
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_add_table(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *tc)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
for (size_t i = 0; i < idl->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &idl->tables[i];
|
|
|
|
|
|
|
|
|
|
if (table->class_ == tc) {
|
|
|
|
|
table->need_table = true;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
OVS_NOT_REACHED();
|
2010-11-16 09:14:52 -08:00
|
|
|
|
}
|
2021-08-26 18:56:13 -04:00
|
|
|
|
|
|
|
|
|
/* Returns 'true' if the 'idl' has seen the table for the 'table_class'
|
|
|
|
|
* in the schema reported by the server. Returns 'false' otherwise.
|
|
|
|
|
*
|
|
|
|
|
* Always returns 'false' if idl has never been connected.
|
|
|
|
|
*
|
|
|
|
|
* Please see ovsdb_idl_compose_monitor_request() which sets
|
|
|
|
|
* 'struct ovsdb_idl_table *'->in_server_schema accordingly.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the
|
|
|
|
|
* "server_has_table" functions generated by ovsdb-idlc. */
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_server_has_table(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *table_class)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table *table =
|
|
|
|
|
ovsdb_idl_table_from_class(idl, table_class);
|
|
|
|
|
|
|
|
|
|
return (table && table->in_server_schema);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns 'true' if the 'idl' has seen the 'column' in the schema
|
|
|
|
|
* reported by the server. Returns 'false' otherwise.
|
|
|
|
|
*
|
|
|
|
|
* Always returns 'false' if idl has never been connected.
|
|
|
|
|
*
|
|
|
|
|
* Please see ovsdb_idl_compose_monitor_request() which sets
|
|
|
|
|
* 'struct ovsdb_idl_table *'->schema_columns accordingly.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the
|
|
|
|
|
* "server_has_column" functions generated by ovsdb-idlc. */
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_server_has_column(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table *table =
|
|
|
|
|
ovsdb_idl_table_from_column(idl, column);
|
|
|
|
|
|
|
|
|
|
return (table->in_server_schema && sset_find(&table->schema_columns,
|
|
|
|
|
column->name));
|
|
|
|
|
}
|
2016-08-13 21:52:27 -07:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
/* A single clause within an ovsdb_idl_condition. */
|
2016-08-13 21:52:27 -07:00
|
|
|
|
struct ovsdb_idl_clause {
|
2016-12-19 20:55:35 -08:00
|
|
|
|
struct hmap_node hmap_node; /* In struct ovsdb_idl_condition. */
|
|
|
|
|
enum ovsdb_function function; /* Never OVSDB_F_TRUE or OVSDB_F_FALSE. */
|
|
|
|
|
const struct ovsdb_idl_column *column; /* Must be nonnull. */
|
|
|
|
|
struct ovsdb_datum arg; /* Has ovsdb_type ->column->type. */
|
2016-08-13 21:52:27 -07:00
|
|
|
|
};
|
2010-11-16 09:14:52 -08:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
static uint32_t
|
|
|
|
|
ovsdb_idl_clause_hash(const struct ovsdb_idl_clause *clause)
|
|
|
|
|
{
|
|
|
|
|
uint32_t hash = hash_pointer(clause->column, clause->function);
|
|
|
|
|
return ovsdb_datum_hash(&clause->arg, &clause->column->type, hash);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
ovsdb_idl_clause_equals(const struct ovsdb_idl_clause *a,
|
|
|
|
|
const struct ovsdb_idl_clause *b)
|
|
|
|
|
{
|
|
|
|
|
return (a->function == b->function
|
|
|
|
|
&& a->column == b->column
|
|
|
|
|
&& ovsdb_datum_equals(&a->arg, &b->arg, &a->column->type));
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-18 11:45:58 +03:00
|
|
|
|
static struct json *
|
|
|
|
|
ovsdb_idl_clause_to_json(const struct ovsdb_idl_clause *clause)
|
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
const char *function = ovsdb_function_to_string(clause->function);
|
|
|
|
|
return json_array_create_3(json_string_create(clause->column->name),
|
|
|
|
|
json_string_create(function),
|
|
|
|
|
ovsdb_datum_to_json(&clause->arg,
|
|
|
|
|
&clause->column->type));
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2016-12-19 20:55:35 -08:00
|
|
|
|
ovsdb_idl_clause_destroy(struct ovsdb_idl_clause *clause)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
if (clause) {
|
2016-07-18 11:45:58 +03:00
|
|
|
|
ovsdb_datum_destroy(&clause->arg, &clause->column->type);
|
2016-12-19 20:55:35 -08:00
|
|
|
|
free(clause);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
2016-12-19 20:55:35 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ovsdb_idl_condition. */
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_condition_init(struct ovsdb_idl_condition *cnd)
|
|
|
|
|
{
|
|
|
|
|
hmap_init(&cnd->clauses);
|
|
|
|
|
cnd->is_true = false;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2016-12-19 20:55:35 -08:00
|
|
|
|
ovsdb_idl_condition_destroy(struct ovsdb_idl_condition *cond)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
if (cond) {
|
|
|
|
|
ovsdb_idl_condition_clear(cond);
|
|
|
|
|
hmap_destroy(&cond->clauses);
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_condition_clear(struct ovsdb_idl_condition *cond)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_clause *clause, *next;
|
|
|
|
|
HMAP_FOR_EACH_SAFE (clause, next, hmap_node, &cond->clauses) {
|
|
|
|
|
hmap_remove(&cond->clauses, &clause->hmap_node);
|
|
|
|
|
ovsdb_idl_clause_destroy(clause);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
2016-12-19 20:55:35 -08:00
|
|
|
|
cond->is_true = false;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_condition_is_true(const struct ovsdb_idl_condition *condition)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
return condition->is_true;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
2016-08-13 21:52:27 -07:00
|
|
|
|
static struct ovsdb_idl_clause *
|
2016-12-19 20:55:35 -08:00
|
|
|
|
ovsdb_idl_condition_find_clause(const struct ovsdb_idl_condition *condition,
|
|
|
|
|
const struct ovsdb_idl_clause *target,
|
|
|
|
|
uint32_t hash)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
struct ovsdb_idl_clause *clause;
|
|
|
|
|
HMAP_FOR_EACH_WITH_HASH (clause, hmap_node, hash, &condition->clauses) {
|
|
|
|
|
if (ovsdb_idl_clause_equals(clause, target)) {
|
|
|
|
|
return clause;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
}
|
2016-08-13 21:52:27 -07:00
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_condition_add_clause__(struct ovsdb_idl_condition *condition,
|
|
|
|
|
const struct ovsdb_idl_clause *src,
|
|
|
|
|
uint32_t hash)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_clause *clause = xmalloc(sizeof *clause);
|
|
|
|
|
clause->function = src->function;
|
|
|
|
|
clause->column = src->column;
|
|
|
|
|
ovsdb_datum_clone(&clause->arg, &src->arg, &src->column->type);
|
|
|
|
|
hmap_insert(&condition->clauses, &clause->hmap_node, hash);
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-13 21:52:27 -07:00
|
|
|
|
/* Adds a clause to the condition for replicating the table with class 'tc' in
|
|
|
|
|
* 'idl'.
|
|
|
|
|
*
|
2016-12-19 20:55:35 -08:00
|
|
|
|
* The IDL replicates only rows in a table that satisfy at least one clause in
|
|
|
|
|
* the table's condition. The default condition for a table has a single
|
|
|
|
|
* clause with function OVSDB_F_TRUE, so that the IDL replicates all rows in
|
|
|
|
|
* the table. When the IDL client replaces the default condition by one of its
|
|
|
|
|
* own, the condition can have any number of clauses. If it has no conditions,
|
|
|
|
|
* then no rows are replicated.
|
2016-08-13 21:52:27 -07:00
|
|
|
|
*
|
2016-12-19 20:55:35 -08:00
|
|
|
|
* Two distinct of clauses can usefully be added:
|
2016-08-13 21:52:27 -07:00
|
|
|
|
*
|
2016-12-19 20:55:35 -08:00
|
|
|
|
* - A 'function' of OVSDB_F_TRUE. A "true" clause causes every row to be
|
|
|
|
|
* replicated, regardless of whether other clauses exist. 'column' and
|
|
|
|
|
* 'arg' are ignored.
|
2016-08-13 21:52:27 -07:00
|
|
|
|
*
|
2016-12-19 20:55:35 -08:00
|
|
|
|
* - Binary 'functions' add a clause of the form "<column> <function>
|
|
|
|
|
* <arg>", e.g. "column == 5" or "column <= 10". In this case, 'arg' must
|
|
|
|
|
* have a type that is compatible with 'column'.
|
2016-08-13 21:52:27 -07:00
|
|
|
|
*/
|
|
|
|
|
void
|
2016-12-19 20:55:35 -08:00
|
|
|
|
ovsdb_idl_condition_add_clause(struct ovsdb_idl_condition *condition,
|
2016-08-13 21:52:27 -07:00
|
|
|
|
enum ovsdb_function function,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
const struct ovsdb_datum *arg)
|
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
if (condition->is_true) {
|
|
|
|
|
/* Adding a clause to an always-true condition has no effect. */
|
|
|
|
|
} else if (function == OVSDB_F_TRUE) {
|
|
|
|
|
ovsdb_idl_condition_add_clause_true(condition);
|
|
|
|
|
} else if (function == OVSDB_F_FALSE) {
|
|
|
|
|
/* Adding a "false" clause never has any effect. */
|
|
|
|
|
} else {
|
|
|
|
|
struct ovsdb_idl_clause clause = {
|
|
|
|
|
.function = function,
|
|
|
|
|
.column = column,
|
|
|
|
|
.arg = *arg,
|
|
|
|
|
};
|
|
|
|
|
uint32_t hash = ovsdb_idl_clause_hash(&clause);
|
|
|
|
|
if (!ovsdb_idl_condition_find_clause(condition, &clause, hash)) {
|
|
|
|
|
ovsdb_idl_condition_add_clause__(condition, &clause, hash);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-08-13 21:52:27 -07:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_condition_add_clause_true(struct ovsdb_idl_condition *condition)
|
|
|
|
|
{
|
|
|
|
|
if (!condition->is_true) {
|
|
|
|
|
ovsdb_idl_condition_clear(condition);
|
|
|
|
|
condition->is_true = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-18 11:45:58 +03:00
|
|
|
|
static struct json *
|
|
|
|
|
ovsdb_idl_condition_to_json(const struct ovsdb_idl_condition *cnd)
|
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
if (cnd->is_true) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return NULL;
|
2016-12-19 20:55:35 -08:00
|
|
|
|
}
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
size_t n = hmap_count(&cnd->clauses);
|
|
|
|
|
if (!n) {
|
|
|
|
|
return json_array_create_1(json_boolean_create(false));
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
struct json **clauses = xmalloc(n * sizeof *clauses);
|
|
|
|
|
const struct ovsdb_idl_clause *clause;
|
|
|
|
|
size_t i = 0;
|
|
|
|
|
HMAP_FOR_EACH (clause, hmap_node, &cnd->clauses) {
|
|
|
|
|
clauses[i++] = ovsdb_idl_clause_to_json(clause);
|
|
|
|
|
}
|
|
|
|
|
ovs_assert(i == n);
|
|
|
|
|
return json_array_create(clauses, n);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
/* Sets the replication condition for 'tc' in 'idl' to 'condition' and
|
|
|
|
|
* arranges to send the new condition to the database server.
|
2017-12-15 10:59:36 -08:00
|
|
|
|
*
|
2020-11-21 11:47:01 -08:00
|
|
|
|
* Return the next conditional update sequence number. When this
|
|
|
|
|
* value and ovsdb_idl_get_condition_seqno() matches, the 'idl'
|
|
|
|
|
* contains rows that match the 'condition'. */
|
|
|
|
|
unsigned int
|
|
|
|
|
ovsdb_idl_set_condition(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *tc,
|
|
|
|
|
const struct ovsdb_idl_condition *condition)
|
2017-12-15 10:59:36 -08:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct json *cond_json = ovsdb_idl_condition_to_json(condition);
|
|
|
|
|
unsigned int seqno = ovsdb_cs_set_condition(idl->cs, tc->name, cond_json);
|
|
|
|
|
json_destroy(cond_json);
|
|
|
|
|
return seqno;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
2018-04-04 10:24:24 -07:00
|
|
|
|
/* Turns off OVSDB_IDL_ALERT and OVSDB_IDL_TRACK for 'column' in 'idl'.
|
2010-08-11 15:41:41 -07:00
|
|
|
|
*
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* This function should be called between ovsdb_idl_create() and the first call
|
|
|
|
|
* to ovsdb_idl_run().
|
|
|
|
|
*/
|
2010-08-11 15:41:41 -07:00
|
|
|
|
void
|
2010-11-16 09:14:52 -08:00
|
|
|
|
ovsdb_idl_omit_alert(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
2010-08-11 15:41:41 -07:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
*ovsdb_idl_get_mode(idl, column) &= ~(OVSDB_IDL_ALERT | OVSDB_IDL_TRACK);
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
|
|
|
|
|
2010-11-16 09:14:52 -08:00
|
|
|
|
/* Sets the mode for 'column' in 'idl' to 0. See the big comment above
|
|
|
|
|
* OVSDB_IDL_MONITOR for details.
|
2010-08-11 15:41:41 -07:00
|
|
|
|
*
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* This function should be called between ovsdb_idl_create() and the first call
|
|
|
|
|
* to ovsdb_idl_run().
|
|
|
|
|
*/
|
2010-08-11 15:41:41 -07:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_omit(struct ovsdb_idl *idl, const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
*ovsdb_idl_get_mode(idl, column) = 0;
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
|
|
|
|
/* Returns the most recent IDL change sequence number that caused a
|
|
|
|
|
* insert, modify or delete update to the table with class 'table_class'.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int
|
|
|
|
|
ovsdb_idl_table_get_seqno(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *table_class)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table
|
2020-11-21 11:47:01 -08:00
|
|
|
|
= ovsdb_idl_table_from_class(idl, table_class);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
unsigned int max_seqno = table->change_seqno[OVSDB_IDL_CHANGE_INSERT];
|
|
|
|
|
|
|
|
|
|
if (max_seqno < table->change_seqno[OVSDB_IDL_CHANGE_MODIFY]) {
|
|
|
|
|
max_seqno = table->change_seqno[OVSDB_IDL_CHANGE_MODIFY];
|
|
|
|
|
}
|
|
|
|
|
if (max_seqno < table->change_seqno[OVSDB_IDL_CHANGE_DELETE]) {
|
|
|
|
|
max_seqno = table->change_seqno[OVSDB_IDL_CHANGE_DELETE];
|
|
|
|
|
}
|
|
|
|
|
return max_seqno;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* For each row that contains tracked columns, IDL stores the most
|
|
|
|
|
* recent IDL change sequence numbers associateed with insert, modify
|
|
|
|
|
* and delete updates to the table.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int
|
|
|
|
|
ovsdb_idl_row_get_seqno(const struct ovsdb_idl_row *row,
|
|
|
|
|
enum ovsdb_idl_change change)
|
|
|
|
|
{
|
|
|
|
|
return row->change_seqno[change];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Turns on OVSDB_IDL_TRACK for 'column' in 'idl', ensuring that
|
|
|
|
|
* all rows whose 'column' is modified are traced. Similarly, insert
|
|
|
|
|
* or delete of rows having 'column' are tracked. Clients are able
|
|
|
|
|
* to retrive the tracked rows with the ovsdb_idl_track_get_*()
|
|
|
|
|
* functions.
|
|
|
|
|
*
|
|
|
|
|
* This function should be called between ovsdb_idl_create() and
|
|
|
|
|
* the first call to ovsdb_idl_run(). The column to be tracked
|
|
|
|
|
* should have OVSDB_IDL_ALERT turned on.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_track_add_column(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
if (!(*ovsdb_idl_get_mode(idl, column) & OVSDB_IDL_ALERT)) {
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
ovsdb_idl_add_column(idl, column);
|
|
|
|
|
}
|
2020-11-21 11:47:01 -08:00
|
|
|
|
*ovsdb_idl_get_mode(idl, column) |= OVSDB_IDL_TRACK;
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_track_add_all(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
size_t i, j;
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
for (i = 0; i < idl->class_->n_tables; i++) {
|
|
|
|
|
const struct ovsdb_idl_table_class *tc = &idl->class_->tables[i];
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
|
|
|
|
for (j = 0; j < tc->n_columns; j++) {
|
|
|
|
|
const struct ovsdb_idl_column *column = &tc->columns[j];
|
|
|
|
|
ovsdb_idl_track_add_column(idl, column);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns true if 'table' has any tracked column. */
|
2021-03-24 10:33:08 +01:00
|
|
|
|
bool
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
ovsdb_idl_track_is_set(struct ovsdb_idl_table *table)
|
|
|
|
|
{
|
|
|
|
|
size_t i;
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
for (i = 0; i < table->class_->n_columns; i++) {
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
if (table->modes[i] & OVSDB_IDL_TRACK) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns the first tracked row in table with class 'table_class'
|
2020-11-23 09:37:47 +01:00
|
|
|
|
* for the specified 'idl'. Returns NULL if there are no tracked rows.
|
|
|
|
|
* Pure orphan rows, i.e. rows that never had any datum, are skipped. */
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
const struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_track_get_first(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *table_class)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table
|
2020-11-21 11:47:01 -08:00
|
|
|
|
= ovsdb_idl_table_from_class(idl, table_class);
|
2020-11-23 09:37:47 +01:00
|
|
|
|
struct ovsdb_idl_row *row;
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
2020-11-23 09:37:47 +01:00
|
|
|
|
LIST_FOR_EACH (row, track_node, &table->track_list) {
|
|
|
|
|
if (!ovsdb_idl_row_is_orphan(row) || row->tracked_old_datum) {
|
|
|
|
|
return row;
|
|
|
|
|
}
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns the next tracked row in table after the specified 'row'
|
2020-11-23 09:37:47 +01:00
|
|
|
|
* (in no particular order). Returns NULL if there are no tracked rows.
|
2020-11-21 11:47:01 -08:00
|
|
|
|
* Pure orphan rows, i.e. rows that never had any datum, are skipped. */
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
const struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_track_get_next(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2020-11-23 09:37:47 +01:00
|
|
|
|
struct ovsdb_idl_table *table = row->table;
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
2020-11-23 09:37:47 +01:00
|
|
|
|
LIST_FOR_EACH_CONTINUE (row, track_node, &table->track_list) {
|
|
|
|
|
if (!ovsdb_idl_row_is_orphan(row) || row->tracked_old_datum) {
|
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
}
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-10 01:12:31 -08:00
|
|
|
|
/* Returns true if a tracked 'column' in 'row' was updated by IDL, false
|
|
|
|
|
* otherwise. The tracking data is cleared by ovsdb_idl_track_clear()
|
|
|
|
|
*
|
|
|
|
|
* Function returns false if 'column' is not tracked (see
|
|
|
|
|
* ovsdb_idl_track_add_column()).
|
|
|
|
|
*/
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_track_is_updated(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
2015-12-10 01:12:31 -08:00
|
|
|
|
column_idx = column - class->columns;
|
|
|
|
|
|
|
|
|
|
if (row->updated && bitmap_is_set(row->updated, column_idx)) {
|
|
|
|
|
return true;
|
|
|
|
|
} else {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_track_clear__(struct ovsdb_idl *idl, bool flush_all)
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
{
|
|
|
|
|
size_t i;
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
for (i = 0; i < idl->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &idl->tables[i];
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
2016-03-25 14:10:22 -07:00
|
|
|
|
if (!ovs_list_is_empty(&table->track_list)) {
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
struct ovsdb_idl_row *row, *next;
|
|
|
|
|
|
|
|
|
|
LIST_FOR_EACH_SAFE(row, next, track_node, &table->track_list) {
|
2015-12-10 01:12:31 -08:00
|
|
|
|
if (row->updated) {
|
|
|
|
|
free(row->updated);
|
|
|
|
|
row->updated = NULL;
|
|
|
|
|
}
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
ovsdb_idl_row_untrack_change(row);
|
2020-10-20 11:07:07 -04:00
|
|
|
|
|
2020-11-30 17:41:29 +01:00
|
|
|
|
if (ovsdb_idl_row_is_orphan(row)) {
|
2019-05-17 12:56:33 -07:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
2020-11-30 17:41:29 +01:00
|
|
|
|
if (row->tracked_old_datum) {
|
|
|
|
|
const struct ovsdb_idl_table_class *class =
|
|
|
|
|
row->table->class_;
|
|
|
|
|
for (size_t c = 0; c < class->n_columns; c++) {
|
|
|
|
|
ovsdb_datum_destroy(&row->tracked_old_datum[c],
|
|
|
|
|
&class->columns[c].type);
|
|
|
|
|
}
|
|
|
|
|
free(row->tracked_old_datum);
|
|
|
|
|
row->tracked_old_datum = NULL;
|
2019-05-17 12:56:33 -07:00
|
|
|
|
}
|
2020-11-30 17:41:41 +01:00
|
|
|
|
|
|
|
|
|
/* Rows that were reused as orphan after being processed
|
|
|
|
|
* for deletion are still in the table hmap and will be
|
|
|
|
|
* cleaned up when their src arcs are removed. These rows
|
|
|
|
|
* will not be reported anymore as "deleted" to IDL
|
|
|
|
|
* clients.
|
|
|
|
|
*
|
|
|
|
|
* The exception is when 'destroy' is explicitly set to
|
|
|
|
|
* 'true' which usually happens when the complete IDL
|
|
|
|
|
* contents are being flushed.
|
|
|
|
|
*/
|
|
|
|
|
if (flush_all || ovs_list_is_empty(&row->dst_arcs)) {
|
|
|
|
|
free(row);
|
|
|
|
|
}
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
/* Flushes the tracked rows. Client calls this function after calling
|
|
|
|
|
* ovsdb_idl_run() and read all tracked rows with the ovsdb_idl_track_get_*()
|
|
|
|
|
* functions. This is usually done at the end of the client's processing
|
|
|
|
|
* loop when it is ready to do ovsdb_idl_run() again.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_track_clear(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_track_clear__(idl, false);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2015-10-15 14:09:37 -07:00
|
|
|
|
static void
|
|
|
|
|
log_parse_update_error(struct ovsdb_error *error)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
2017-12-08 13:24:27 -08:00
|
|
|
|
if (!VLOG_DROP_WARN(&syntax_rl)) {
|
|
|
|
|
char *s = ovsdb_error_to_string(error);
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "%s", s);
|
|
|
|
|
free(s);
|
|
|
|
|
}
|
|
|
|
|
ovsdb_error_destroy(error);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static struct ovsdb_error *
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_parse_update__(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_cs_db_update *du)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
2020-12-01 18:15:11 -08:00
|
|
|
|
for (size_t i = 0; i < du->n; i++) {
|
|
|
|
|
const struct ovsdb_cs_table_update *tu = &du->table_updates[i];
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovsdb_idl_table *table = shash_find_data(&idl->table_by_name,
|
2020-12-01 18:15:11 -08:00
|
|
|
|
tu->table_name);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
if (!table) {
|
|
|
|
|
return ovsdb_syntax_error(
|
2020-12-01 18:15:11 -08:00
|
|
|
|
NULL, NULL, "update to unknown table \"%s\"", tu->table_name);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2015-10-15 14:09:37 -07:00
|
|
|
|
|
2020-12-01 18:15:11 -08:00
|
|
|
|
for (size_t j = 0; j < tu->n; j++) {
|
|
|
|
|
const struct ovsdb_cs_row_update *ru = &tu->row_updates[j];
|
|
|
|
|
switch (ovsdb_idl_process_update(table, ru)) {
|
2020-07-02 16:20:57 +02:00
|
|
|
|
case OVSDB_IDL_UPDATE_DB_CHANGED:
|
2020-11-21 11:47:01 -08:00
|
|
|
|
idl->change_seqno++;
|
2020-07-02 16:20:57 +02:00
|
|
|
|
break;
|
|
|
|
|
case OVSDB_IDL_UPDATE_NO_CHANGES:
|
|
|
|
|
break;
|
|
|
|
|
case OVSDB_IDL_UPDATE_INCONSISTENT:
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_flag_inconsistency(idl->cs);
|
2020-07-02 16:20:57 +02:00
|
|
|
|
return ovsdb_error(NULL,
|
2020-12-01 18:15:11 -08:00
|
|
|
|
"row update received for inconsistent "
|
2020-07-02 16:20:57 +02:00
|
|
|
|
"IDL: reconnecting IDL and resync all "
|
2020-12-01 18:15:11 -08:00
|
|
|
|
"data");
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_parse_update(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_cs_update_event *update)
|
2017-12-15 10:59:36 -08:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
if (update->monitor_reply) {
|
|
|
|
|
/* XXX This isn't semantically required, because we only need to
|
|
|
|
|
* increment change_seqno if there's a real change, which we'll do
|
|
|
|
|
* below, but older versions of the IDL always incremented change_seqno
|
|
|
|
|
* when a monitor reply was received and if we don't do it then tests
|
|
|
|
|
* will fail. */
|
|
|
|
|
idl->change_seqno++;
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-01 18:15:11 -08:00
|
|
|
|
struct ovsdb_cs_db_update *du;
|
|
|
|
|
struct ovsdb_error *error = ovsdb_cs_parse_db_update(
|
2020-11-21 11:47:01 -08:00
|
|
|
|
update->table_updates, update->version, &du);
|
2020-12-01 18:15:11 -08:00
|
|
|
|
if (!error) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
if (update->clear) {
|
|
|
|
|
ovsdb_idl_clear(idl);
|
|
|
|
|
}
|
|
|
|
|
error = ovsdb_idl_parse_update__(idl, du);
|
2020-12-01 18:15:11 -08:00
|
|
|
|
}
|
|
|
|
|
ovsdb_cs_db_update_destroy(du);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (error) {
|
|
|
|
|
log_parse_update_error(error);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
/* Reparses references to rows that have been deleted in the current IDL run.
|
|
|
|
|
*
|
|
|
|
|
* To ensure that reference sources that are deleted are not reparsed,
|
|
|
|
|
* this function must be called after all updates have been processed in
|
|
|
|
|
* the current IDL run, i.e., after all calls to ovsdb_idl_parse_update().
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_reparse_deleted(struct ovsdb_idl *db)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row, *next;
|
|
|
|
|
|
|
|
|
|
LIST_FOR_EACH_SAFE (row, next, track_node, &db->deleted_untracked_rows) {
|
|
|
|
|
ovsdb_idl_row_untrack_change(row);
|
2021-03-24 10:33:40 +01:00
|
|
|
|
add_tracked_change_for_references(row);
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
ovsdb_idl_row_reparse_backrefs(row);
|
|
|
|
|
|
|
|
|
|
/* Orphan rows that are still unreferenced or are part of tables that
|
|
|
|
|
* have change tracking enabled should be added to their table's
|
|
|
|
|
* 'track_list'.
|
|
|
|
|
*/
|
|
|
|
|
if (ovs_list_is_empty(&row->dst_arcs)
|
|
|
|
|
|| ovsdb_idl_track_is_set(row->table)) {
|
|
|
|
|
ovsdb_idl_row_track_change(row, OVSDB_IDL_CHANGE_DELETE);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_get_row(struct ovsdb_idl_table *table, const struct uuid *uuid)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row;
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_WITH_HASH (row, hmap_node, uuid_hash(uuid), &table->rows) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
if (uuid_equals(&row->uuid, uuid)) {
|
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-02 16:20:57 +02:00
|
|
|
|
/* Returns OVSDB_IDL_UPDATE_DB_CHANGED if a column with mode
|
|
|
|
|
* OVSDB_IDL_MODE_RW changed.
|
|
|
|
|
*
|
|
|
|
|
* Some IDL inconsistencies can be detected when processing updates:
|
|
|
|
|
* - trying to insert an already existing row
|
|
|
|
|
* - trying to update a missing row
|
|
|
|
|
* - trying to delete a non existent row
|
|
|
|
|
*
|
|
|
|
|
* In such cases OVSDB_IDL_UPDATE_INCONSISTENT is returned.
|
|
|
|
|
* Even though the IDL client could recover, it's best to report the
|
|
|
|
|
* inconsistent state because the state the server is in is unknown so the
|
|
|
|
|
* safest thing to do is to retry (potentially connecting to a new server).
|
|
|
|
|
*
|
|
|
|
|
* Returns OVSDB_IDL_UPDATE_NO_CHANGES otherwise.
|
|
|
|
|
*/
|
|
|
|
|
static enum update_result
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_process_update(struct ovsdb_idl_table *table,
|
2020-12-01 18:15:11 -08:00
|
|
|
|
const struct ovsdb_cs_row_update *ru)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
2020-12-01 18:15:11 -08:00
|
|
|
|
const struct uuid *uuid = &ru->row_uuid;
|
|
|
|
|
struct ovsdb_idl_row *row = ovsdb_idl_get_row(table, uuid);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2020-12-01 18:15:11 -08:00
|
|
|
|
switch (ru->type) {
|
|
|
|
|
case OVSDB_CS_ROW_DELETE:
|
2009-12-02 11:26:15 -08:00
|
|
|
|
if (row && !ovsdb_idl_row_is_orphan(row)) {
|
|
|
|
|
/* XXX perhaps we should check the 'old' values? */
|
|
|
|
|
ovsdb_idl_delete_row(row);
|
|
|
|
|
} else {
|
2020-07-02 16:20:57 +02:00
|
|
|
|
VLOG_ERR_RL(&semantic_rl, "cannot delete missing row "UUID_FMT" "
|
|
|
|
|
"from table %s",
|
|
|
|
|
UUID_ARGS(uuid), table->class_->name);
|
|
|
|
|
return OVSDB_IDL_UPDATE_INCONSISTENT;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2020-12-01 18:15:11 -08:00
|
|
|
|
break;
|
2015-10-15 14:09:37 -07:00
|
|
|
|
|
2020-12-01 18:15:11 -08:00
|
|
|
|
case OVSDB_CS_ROW_INSERT:
|
2015-10-15 14:09:37 -07:00
|
|
|
|
if (!row) {
|
2020-12-01 18:15:11 -08:00
|
|
|
|
ovsdb_idl_insert_row(ovsdb_idl_row_create(table, uuid),
|
|
|
|
|
ru->columns);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
} else if (ovsdb_idl_row_is_orphan(row)) {
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
ovsdb_idl_row_untrack_change(row);
|
2020-12-01 18:15:11 -08:00
|
|
|
|
ovsdb_idl_insert_row(row, ru->columns);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
} else {
|
2020-07-02 16:20:57 +02:00
|
|
|
|
VLOG_ERR_RL(&semantic_rl, "cannot add existing row "UUID_FMT" to "
|
|
|
|
|
"table %s", UUID_ARGS(uuid), table->class_->name);
|
|
|
|
|
return OVSDB_IDL_UPDATE_INCONSISTENT;
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
2020-12-01 18:15:11 -08:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case OVSDB_CS_ROW_UPDATE:
|
|
|
|
|
case OVSDB_CS_ROW_XOR:
|
2015-10-15 14:09:37 -07:00
|
|
|
|
if (row) {
|
|
|
|
|
if (!ovsdb_idl_row_is_orphan(row)) {
|
2020-12-01 18:15:11 -08:00
|
|
|
|
return ovsdb_idl_modify_row(row, ru->columns,
|
|
|
|
|
ru->type == OVSDB_CS_ROW_XOR)
|
2020-07-02 16:20:57 +02:00
|
|
|
|
? OVSDB_IDL_UPDATE_DB_CHANGED
|
|
|
|
|
: OVSDB_IDL_UPDATE_NO_CHANGES;
|
2015-10-15 14:09:37 -07:00
|
|
|
|
} else {
|
2020-07-02 16:20:57 +02:00
|
|
|
|
VLOG_ERR_RL(&semantic_rl, "cannot modify missing but "
|
|
|
|
|
"referenced row "UUID_FMT" in table %s",
|
|
|
|
|
UUID_ARGS(uuid), table->class_->name);
|
|
|
|
|
return OVSDB_IDL_UPDATE_INCONSISTENT;
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
|
|
|
|
} else {
|
2020-07-02 16:20:57 +02:00
|
|
|
|
VLOG_ERR_RL(&semantic_rl, "cannot modify missing row "UUID_FMT" "
|
|
|
|
|
"in table %s", UUID_ARGS(uuid), table->class_->name);
|
|
|
|
|
return OVSDB_IDL_UPDATE_INCONSISTENT;
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
2020-12-01 18:15:11 -08:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
OVS_NOT_REACHED();
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
|
|
|
|
|
2020-07-02 16:20:57 +02:00
|
|
|
|
return OVSDB_IDL_UPDATE_DB_CHANGED;
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
|
|
|
|
|
2020-10-20 11:07:07 -04:00
|
|
|
|
/* Recursively add rows to tracked change lists for all rows that reference
|
|
|
|
|
'row'. */
|
2018-08-13 10:48:03 -07:00
|
|
|
|
static void
|
|
|
|
|
add_tracked_change_for_references(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2020-10-20 11:07:07 -04:00
|
|
|
|
const struct ovsdb_idl_arc *arc;
|
|
|
|
|
LIST_FOR_EACH (arc, dst_node, &row->dst_arcs) {
|
|
|
|
|
struct ovsdb_idl_row *ref = arc->src;
|
|
|
|
|
|
|
|
|
|
if (ovs_list_is_empty(&ref->track_node) &&
|
|
|
|
|
ovsdb_idl_track_is_set(ref->table)) {
|
|
|
|
|
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
ovsdb_idl_row_track_change(ref, OVSDB_IDL_CHANGE_MODIFY);
|
2020-10-20 11:07:07 -04:00
|
|
|
|
add_tracked_change_for_references(ref);
|
2018-08-13 10:48:03 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2015-10-15 14:09:37 -07:00
|
|
|
|
/* Returns true if a column with mode OVSDB_IDL_MODE_RW changed, false
|
|
|
|
|
* otherwise.
|
|
|
|
|
*
|
|
|
|
|
* Change 'row' either with the content of 'row_json' or by apply 'diff'.
|
|
|
|
|
* Caller needs to provide either valid 'row_json' or 'diff', but not
|
|
|
|
|
* both. */
|
|
|
|
|
static bool
|
2020-12-01 18:15:11 -08:00
|
|
|
|
ovsdb_idl_row_change(struct ovsdb_idl_row *row, const struct shash *values,
|
|
|
|
|
bool xor, enum ovsdb_idl_change change)
|
2015-10-15 14:09:37 -07:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table = row->table;
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = table->class_;
|
2015-10-15 14:09:37 -07:00
|
|
|
|
struct shash_node *node;
|
|
|
|
|
bool changed = false;
|
2020-11-21 11:47:01 -08:00
|
|
|
|
|
2020-12-01 18:15:11 -08:00
|
|
|
|
SHASH_FOR_EACH (node, values) {
|
2015-10-15 14:09:37 -07:00
|
|
|
|
const char *column_name = node->name;
|
|
|
|
|
const struct ovsdb_idl_column *column;
|
|
|
|
|
struct ovsdb_datum datum;
|
|
|
|
|
struct ovsdb_error *error;
|
|
|
|
|
unsigned int column_idx;
|
|
|
|
|
struct ovsdb_datum *old;
|
|
|
|
|
|
|
|
|
|
column = shash_find_data(&table->columns, column_name);
|
|
|
|
|
if (!column) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "unknown column %s updating row "UUID_FMT,
|
|
|
|
|
column_name, UUID_ARGS(&row->uuid));
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
column_idx = column - table->class_->columns;
|
2017-08-11 11:06:47 -07:00
|
|
|
|
old = &row->old_datum[column_idx];
|
2015-10-15 14:09:37 -07:00
|
|
|
|
|
|
|
|
|
error = NULL;
|
2020-12-01 18:15:11 -08:00
|
|
|
|
if (xor) {
|
2015-10-15 14:09:37 -07:00
|
|
|
|
struct ovsdb_datum diff;
|
|
|
|
|
|
|
|
|
|
error = ovsdb_transient_datum_from_json(&diff, &column->type,
|
|
|
|
|
node->data);
|
|
|
|
|
if (!error) {
|
|
|
|
|
error = ovsdb_datum_apply_diff(&datum, old, &diff,
|
|
|
|
|
&column->type);
|
|
|
|
|
ovsdb_datum_destroy(&diff, &column->type);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
error = ovsdb_datum_from_json(&datum, &column->type, node->data,
|
|
|
|
|
NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!error) {
|
2010-08-11 15:29:36 -07:00
|
|
|
|
if (!ovsdb_datum_equals(old, &datum, &column->type)) {
|
|
|
|
|
ovsdb_datum_swap(old, &datum);
|
2010-11-16 09:14:52 -08:00
|
|
|
|
if (table->modes[column_idx] & OVSDB_IDL_ALERT) {
|
2010-08-11 15:29:36 -07:00
|
|
|
|
changed = true;
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
row->change_seqno[change]
|
|
|
|
|
= row->table->change_seqno[change]
|
2020-11-21 11:47:01 -08:00
|
|
|
|
= row->table->idl->change_seqno + 1;
|
2020-10-20 11:07:07 -04:00
|
|
|
|
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
if (table->modes[column_idx] & OVSDB_IDL_TRACK) {
|
2020-10-20 11:07:07 -04:00
|
|
|
|
if (ovs_list_is_empty(&row->track_node) &&
|
|
|
|
|
ovsdb_idl_track_is_set(row->table)) {
|
|
|
|
|
ovs_list_push_back(&row->table->track_list,
|
|
|
|
|
&row->track_node);
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-13 10:48:03 -07:00
|
|
|
|
add_tracked_change_for_references(row);
|
2015-12-10 01:12:31 -08:00
|
|
|
|
if (!row->updated) {
|
|
|
|
|
row->updated = bitmap_allocate(class->n_columns);
|
|
|
|
|
}
|
|
|
|
|
bitmap_set1(row->updated, column_idx);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
}
|
2010-08-11 15:29:36 -07:00
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
/* Didn't really change but the OVSDB monitor protocol always
|
|
|
|
|
* includes every value in a row. */
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
2010-08-11 15:29:36 -07:00
|
|
|
|
|
|
|
|
|
ovsdb_datum_destroy(&datum, &column->type);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
} else {
|
2017-12-13 11:32:28 -08:00
|
|
|
|
char *s = ovsdb_error_to_string_free(error);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "error parsing column %s in row "UUID_FMT
|
|
|
|
|
" in table %s: %s", column_name,
|
2017-08-11 11:06:44 -07:00
|
|
|
|
UUID_ARGS(&row->uuid), table->class_->name, s);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
free(s);
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-08-11 15:41:41 -07:00
|
|
|
|
return changed;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-03-03 09:54:43 -08:00
|
|
|
|
/* When a row A refers to row B through a column with a "refTable" constraint,
|
|
|
|
|
* but row B does not exist, row B is called an "orphan row". Orphan rows
|
|
|
|
|
* should not persist, because the database enforces referential integrity, but
|
|
|
|
|
* they can appear transiently as changes from the database are received (the
|
|
|
|
|
* database doesn't try to topologically sort them and circular references mean
|
|
|
|
|
* it isn't always possible anyhow).
|
|
|
|
|
*
|
|
|
|
|
* This function returns true if 'row' is an orphan row, otherwise false.
|
|
|
|
|
*/
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_row_is_orphan(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-11 11:06:47 -07:00
|
|
|
|
return !row->old_datum && !row->new_datum;
|
2010-03-03 09:54:43 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-03-03 09:59:47 -08:00
|
|
|
|
/* Returns true if 'row' is conceptually part of the database as modified by
|
|
|
|
|
* the current transaction (if any), false otherwise.
|
|
|
|
|
*
|
|
|
|
|
* This function will return true if 'row' is not an orphan (see the comment on
|
|
|
|
|
* ovsdb_idl_row_is_orphan()) and:
|
|
|
|
|
*
|
|
|
|
|
* - 'row' exists in the database and has not been deleted within the
|
|
|
|
|
* current transaction (if any).
|
|
|
|
|
*
|
|
|
|
|
* - 'row' was inserted within the current transaction and has not been
|
|
|
|
|
* deleted. (In the latter case you should not have passed 'row' in at
|
|
|
|
|
* all, because ovsdb_idl_txn_delete() freed it.)
|
|
|
|
|
*
|
|
|
|
|
* This function will return false if 'row' is an orphan or if 'row' was
|
|
|
|
|
* deleted within the current transaction.
|
|
|
|
|
*/
|
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_row_exists(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-11 11:06:46 -07:00
|
|
|
|
return row->new_datum != NULL;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-01-25 10:15:17 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_parse(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2010-01-25 10:15:17 -08:00
|
|
|
|
size_t i;
|
|
|
|
|
|
2019-05-17 12:56:33 -07:00
|
|
|
|
if (row->parsed) {
|
|
|
|
|
ovsdb_idl_row_unparse(row);
|
|
|
|
|
}
|
2010-01-25 10:15:17 -08:00
|
|
|
|
for (i = 0; i < class->n_columns; i++) {
|
|
|
|
|
const struct ovsdb_idl_column *c = &class->columns[i];
|
2017-08-11 11:06:47 -07:00
|
|
|
|
(c->parse)(row, &row->old_datum[i]);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
}
|
2019-05-17 12:56:33 -07:00
|
|
|
|
row->parsed = true;
|
2010-01-25 10:15:17 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_unparse(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2010-01-25 10:15:17 -08:00
|
|
|
|
size_t i;
|
|
|
|
|
|
2019-05-17 12:56:33 -07:00
|
|
|
|
if (!row->parsed) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2010-01-25 10:15:17 -08:00
|
|
|
|
for (i = 0; i < class->n_columns; i++) {
|
|
|
|
|
const struct ovsdb_idl_column *c = &class->columns[i];
|
|
|
|
|
(c->unparse)(row);
|
|
|
|
|
}
|
2019-05-17 12:56:33 -07:00
|
|
|
|
row->parsed = false;
|
2010-01-25 10:15:17 -08:00
|
|
|
|
}
|
2017-08-03 14:20:15 -04:00
|
|
|
|
|
|
|
|
|
/* The OVSDB-IDL Compound Indexes feature allows for the creation of custom
|
|
|
|
|
* table indexes over one or more columns in the IDL. These indexes provide
|
|
|
|
|
* the ability to retrieve rows matching a particular search criteria and to
|
|
|
|
|
* iterate over a subset of rows in a defined order.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Generic comparator that can compare each index, using the custom
|
|
|
|
|
* configuration (an struct ovsdb_idl_index) passed to it.
|
|
|
|
|
* Not intended for direct usage.
|
|
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
ovsdb_idl_index_generic_comparer(const void *a,
|
|
|
|
|
const void *b, const void *conf)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_column *column;
|
|
|
|
|
const struct ovsdb_idl_index *index;
|
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
|
|
index = CONST_CAST(struct ovsdb_idl_index *, conf);
|
|
|
|
|
|
|
|
|
|
if (a == b) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < index->n_columns; i++) {
|
|
|
|
|
int val;
|
|
|
|
|
if (index->columns[i].comparer) {
|
|
|
|
|
val = index->columns[i].comparer(a, b);
|
|
|
|
|
} else {
|
|
|
|
|
column = index->columns[i].column;
|
|
|
|
|
const struct ovsdb_idl_row *row_a, *row_b;
|
|
|
|
|
row_a = CONST_CAST(struct ovsdb_idl_row *, a);
|
|
|
|
|
row_b = CONST_CAST(struct ovsdb_idl_row *, b);
|
|
|
|
|
const struct ovsdb_datum *datum_a, *datum_b;
|
|
|
|
|
datum_a = ovsdb_idl_read(row_a, column);
|
|
|
|
|
datum_b = ovsdb_idl_read(row_b, column);
|
|
|
|
|
val = ovsdb_datum_compare_3way(datum_a, datum_b, &column->type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (val) {
|
2018-06-07 21:07:34 -07:00
|
|
|
|
return index->columns[i].order == OVSDB_INDEX_ASC ? val : -val;
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If ins_del is true then a row is being inserted into or deleted from
|
|
|
|
|
* the index list. In this case, we augment the search key with
|
|
|
|
|
* additional values (row UUID and memory address) to create a unique
|
|
|
|
|
* search key in order to locate the correct entry efficiently and to
|
|
|
|
|
* ensure that the correct entry is deleted in the case of a "delete"
|
|
|
|
|
* operation.
|
|
|
|
|
*/
|
|
|
|
|
if (index->ins_del) {
|
|
|
|
|
const struct ovsdb_idl_row *row_a, *row_b;
|
|
|
|
|
|
|
|
|
|
row_a = (const struct ovsdb_idl_row *) a;
|
|
|
|
|
row_b = (const struct ovsdb_idl_row *) b;
|
|
|
|
|
int value = uuid_compare_3way(&row_a->uuid, &row_b->uuid);
|
|
|
|
|
|
|
|
|
|
return value ? value : (a < b) - (a > b);
|
|
|
|
|
} else {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
/* Creates a new index for the given 'idl' and with the 'n' specified
|
|
|
|
|
* 'columns'.
|
|
|
|
|
*
|
|
|
|
|
* All indexes must be created before the first call to ovsdb_idl_run(). */
|
|
|
|
|
struct ovsdb_idl_index *
|
|
|
|
|
ovsdb_idl_index_create(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_index_column *columns,
|
|
|
|
|
size_t n)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovs_assert(n > 0);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_index *index = xzalloc(sizeof *index);
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
index->table = ovsdb_idl_table_from_column(idl, columns[0].column);
|
2018-06-07 21:07:34 -07:00
|
|
|
|
for (size_t i = 0; i < n; i++) {
|
|
|
|
|
const struct ovsdb_idl_index_column *c = &columns[i];
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovs_assert(ovsdb_idl_table_from_column(idl,
|
|
|
|
|
c->column) == index->table);
|
|
|
|
|
ovs_assert(*ovsdb_idl_get_mode(idl, c->column) & OVSDB_IDL_MONITOR);
|
2018-06-07 21:07:34 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
index->columns = xmemdup(columns, n * sizeof *columns);
|
|
|
|
|
index->n_columns = n;
|
2017-08-03 14:20:15 -04:00
|
|
|
|
index->skiplist = skiplist_create(ovsdb_idl_index_generic_comparer, index);
|
2018-06-07 21:07:34 -07:00
|
|
|
|
|
|
|
|
|
ovs_list_push_back(&index->table->indexes, &index->node);
|
|
|
|
|
|
2017-08-03 14:20:15 -04:00
|
|
|
|
return index;
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_index *
|
|
|
|
|
ovsdb_idl_index_create1(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column1)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_index_column columns[] = {
|
|
|
|
|
{ .column = column1 },
|
|
|
|
|
};
|
|
|
|
|
return ovsdb_idl_index_create(idl, columns, ARRAY_SIZE(columns));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_index *
|
|
|
|
|
ovsdb_idl_index_create2(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column1,
|
|
|
|
|
const struct ovsdb_idl_column *column2)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_index_column columns[] = {
|
|
|
|
|
{ .column = column1 },
|
|
|
|
|
{ .column = column2 },
|
|
|
|
|
};
|
|
|
|
|
return ovsdb_idl_index_create(idl, columns, ARRAY_SIZE(columns));
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-03 14:20:15 -04:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_destroy_indexes(struct ovsdb_idl_table *table)
|
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_index *index, *next;
|
|
|
|
|
LIST_FOR_EACH_SAFE (index, next, node, &table->indexes) {
|
2017-08-03 14:20:15 -04:00
|
|
|
|
skiplist_destroy(index->skiplist, NULL);
|
|
|
|
|
free(index->columns);
|
2018-06-07 21:07:34 -07:00
|
|
|
|
free(index);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_add_to_indexes(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table = row->table;
|
|
|
|
|
struct ovsdb_idl_index *index;
|
2018-06-07 21:07:34 -07:00
|
|
|
|
LIST_FOR_EACH (index, node, &table->indexes) {
|
2017-08-03 14:20:15 -04:00
|
|
|
|
index->ins_del = true;
|
|
|
|
|
skiplist_insert(index->skiplist, row);
|
|
|
|
|
index->ins_del = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_remove_from_indexes(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table = row->table;
|
|
|
|
|
struct ovsdb_idl_index *index;
|
2018-06-07 21:07:34 -07:00
|
|
|
|
LIST_FOR_EACH (index, node, &table->indexes) {
|
2017-08-03 14:20:15 -04:00
|
|
|
|
index->ins_del = true;
|
|
|
|
|
skiplist_delete(index->skiplist, row);
|
|
|
|
|
index->ins_del = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
/* Writes a datum in an ovsdb_idl_row, and updates the corresponding field in
|
|
|
|
|
* the table record. Not intended for direct usage. */
|
2017-08-03 14:20:15 -04:00
|
|
|
|
void
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_index_write(struct ovsdb_idl_row *const_row,
|
2017-08-03 14:20:15 -04:00
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum,
|
|
|
|
|
const struct ovsdb_idl_table_class *class)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, const_row);
|
|
|
|
|
size_t column_idx = column - class->columns;
|
|
|
|
|
|
|
|
|
|
if (bitmap_is_set(row->written, column_idx)) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
free(row->new_datum[column_idx].values);
|
|
|
|
|
free(row->new_datum[column_idx].keys);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
} else {
|
|
|
|
|
bitmap_set1(row->written, column_idx);
|
|
|
|
|
}
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum[column_idx] = *datum;
|
2017-08-03 14:20:15 -04:00
|
|
|
|
(column->unparse)(row);
|
2017-08-11 11:06:46 -07:00
|
|
|
|
(column->parse)(row, &row->new_datum[column_idx]);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
|
2017-10-30 12:21:49 -07:00
|
|
|
|
/* Magic UUID for index rows */
|
|
|
|
|
static const struct uuid index_row_uuid = {
|
|
|
|
|
.parts = {0xdeadbeef,
|
|
|
|
|
0xdeadbeef,
|
|
|
|
|
0xdeadbeef,
|
|
|
|
|
0xdeadbeef}};
|
|
|
|
|
|
|
|
|
|
/* Check if a row is an index row */
|
|
|
|
|
static bool
|
2018-06-07 21:07:34 -07:00
|
|
|
|
is_index_row(const struct ovsdb_idl_row *row)
|
2017-10-30 12:21:49 -07:00
|
|
|
|
{
|
|
|
|
|
return uuid_equals(&row->uuid, &index_row_uuid);
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-03 14:20:15 -04:00
|
|
|
|
/* Initializes a row for use in an indexed query.
|
|
|
|
|
* Not intended for direct usage.
|
|
|
|
|
*/
|
|
|
|
|
struct ovsdb_idl_row *
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_index_init_row(struct ovsdb_idl_index *index)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = index->table->class_;
|
2017-08-03 14:20:15 -04:00
|
|
|
|
struct ovsdb_idl_row *row = xzalloc(class->allocation_size);
|
|
|
|
|
class->row_init(row);
|
2017-10-30 12:21:49 -07:00
|
|
|
|
row->uuid = index_row_uuid;
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum = xmalloc(class->n_columns * sizeof *row->new_datum);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
row->written = bitmap_allocate(class->n_columns);
|
2018-06-07 21:07:34 -07:00
|
|
|
|
row->table = index->table;
|
2017-10-30 12:21:49 -07:00
|
|
|
|
/* arcs are not used for index row, but it doesn't harm to initialize */
|
|
|
|
|
ovs_list_init(&row->src_arcs);
|
|
|
|
|
ovs_list_init(&row->dst_arcs);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Destroys 'row_' and frees all associated memory. This function is intended
|
|
|
|
|
* to be used indirectly through one of the "index_destroy_row" functions
|
|
|
|
|
* generated by ovsdb-idlc.
|
|
|
|
|
*/
|
|
|
|
|
void
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_index_destroy_row(const struct ovsdb_idl_row *row_)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2017-08-03 14:20:15 -04:00
|
|
|
|
const struct ovsdb_idl_column *c;
|
|
|
|
|
size_t i;
|
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovs_assert(is_index_row(row_));
|
2017-10-30 12:21:49 -07:00
|
|
|
|
ovs_assert(ovs_list_is_empty(&row_->src_arcs));
|
|
|
|
|
ovs_assert(ovs_list_is_empty(&row_->dst_arcs));
|
2017-08-03 14:20:15 -04:00
|
|
|
|
BITMAP_FOR_EACH_1 (i, class->n_columns, row->written) {
|
|
|
|
|
c = &class->columns[i];
|
|
|
|
|
(c->unparse) (row);
|
2021-09-22 09:28:50 +02:00
|
|
|
|
ovsdb_datum_destroy(&row->new_datum[i], &c->type);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
2017-08-11 11:06:46 -07:00
|
|
|
|
free(row->new_datum);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
free(row->written);
|
|
|
|
|
free(row);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_row *
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_index_find(struct ovsdb_idl_index *index,
|
|
|
|
|
const struct ovsdb_idl_row *target)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
return skiplist_get_data(skiplist_find(index->skiplist, target));
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_cursor
|
|
|
|
|
ovsdb_idl_cursor_first(struct ovsdb_idl_index *index)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct skiplist_node *node = skiplist_first(index->skiplist);
|
|
|
|
|
return (struct ovsdb_idl_cursor) { index, node };
|
|
|
|
|
}
|
2017-08-03 14:20:15 -04:00
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_cursor
|
|
|
|
|
ovsdb_idl_cursor_first_eq(struct ovsdb_idl_index *index,
|
|
|
|
|
const struct ovsdb_idl_row *target)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct skiplist_node *node = skiplist_find(index->skiplist, target);
|
|
|
|
|
return (struct ovsdb_idl_cursor) { index, node };
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_cursor
|
|
|
|
|
ovsdb_idl_cursor_first_ge(struct ovsdb_idl_index *index,
|
|
|
|
|
const struct ovsdb_idl_row *target)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct skiplist_node *node = (target
|
|
|
|
|
? skiplist_forward_to(index->skiplist,
|
|
|
|
|
target)
|
|
|
|
|
: skiplist_first(index->skiplist));
|
|
|
|
|
return (struct ovsdb_idl_cursor) { index, node };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_cursor_next(struct ovsdb_idl_cursor *cursor)
|
|
|
|
|
{
|
|
|
|
|
cursor->position = skiplist_next(cursor->position);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_cursor_next_eq(struct ovsdb_idl_cursor *cursor)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *data = skiplist_get_data(cursor->position);
|
|
|
|
|
struct skiplist_node *next_position = skiplist_next(cursor->position);
|
|
|
|
|
struct ovsdb_idl_row *next_data = skiplist_get_data(next_position);
|
|
|
|
|
cursor->position = (!ovsdb_idl_index_compare(cursor->index,
|
|
|
|
|
data, next_data)
|
|
|
|
|
? next_position : NULL);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_row *
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_cursor_data(struct ovsdb_idl_cursor *cursor)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
return skiplist_get_data(cursor->position);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns the result of comparing two rows using the comparison function
|
|
|
|
|
* for this index.
|
|
|
|
|
* Returns:
|
|
|
|
|
* < 0 if a < b
|
|
|
|
|
* 0 if a == b
|
|
|
|
|
* > 0 if a > b
|
|
|
|
|
* When the pointer to either row is NULL, this function considers NULL to be
|
|
|
|
|
* greater than any other value, and NULL == NULL.
|
|
|
|
|
*/
|
|
|
|
|
int
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_index_compare(struct ovsdb_idl_index *index,
|
|
|
|
|
const struct ovsdb_idl_row *a,
|
|
|
|
|
const struct ovsdb_idl_row *b)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
|
|
|
|
if (a && b) {
|
2018-06-07 21:07:34 -07:00
|
|
|
|
return ovsdb_idl_index_generic_comparer(a, b, index);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
} else if (!a && !b) {
|
|
|
|
|
return 0;
|
|
|
|
|
} else if (a) {
|
|
|
|
|
return -1;
|
|
|
|
|
} else {
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-01-25 10:15:17 -08:00
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static void
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_row_clear_old(struct ovsdb_idl_row *row)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovs_assert(row->old_datum == row->new_datum);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
if (!ovsdb_idl_row_is_orphan(row)) {
|
2020-11-30 17:41:14 +01:00
|
|
|
|
if (ovsdb_idl_track_is_set(row->table) && !row->tracked_old_datum) {
|
2019-05-17 12:56:33 -07:00
|
|
|
|
row->tracked_old_datum = row->old_datum;
|
|
|
|
|
} else {
|
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
|
|
|
|
size_t i;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2019-05-17 12:56:33 -07:00
|
|
|
|
for (i = 0; i < class->n_columns; i++) {
|
|
|
|
|
ovsdb_datum_destroy(&row->old_datum[i],
|
|
|
|
|
&class->columns[i].type);
|
|
|
|
|
}
|
|
|
|
|
free(row->old_datum);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
2017-08-11 11:06:47 -07:00
|
|
|
|
row->old_datum = row->new_datum = NULL;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_clear_new(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (row->old_datum != row->new_datum) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (row->new_datum) {
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
size_t i;
|
|
|
|
|
|
2010-06-24 15:31:18 -07:00
|
|
|
|
if (row->written) {
|
|
|
|
|
BITMAP_FOR_EACH_1 (i, class->n_columns, row->written) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovsdb_datum_destroy(&row->new_datum[i],
|
|
|
|
|
&class->columns[i].type);
|
2010-06-24 15:31:18 -07:00
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
2017-08-11 11:06:46 -07:00
|
|
|
|
free(row->new_datum);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
free(row->written);
|
|
|
|
|
row->written = NULL;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2017-08-11 11:06:47 -07:00
|
|
|
|
row->new_datum = row->old_datum;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_clear_arcs(struct ovsdb_idl_row *row, bool destroy_dsts)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_arc *arc, *next;
|
|
|
|
|
|
|
|
|
|
/* Delete all forward arcs. If 'destroy_dsts', destroy any orphaned rows
|
2018-08-13 10:48:00 -07:00
|
|
|
|
* that this causes to be unreferenced.
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
*/
|
2010-09-17 10:33:10 -07:00
|
|
|
|
LIST_FOR_EACH_SAFE (arc, next, src_node, &row->src_arcs) {
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_remove(&arc->dst_node);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
if (destroy_dsts
|
|
|
|
|
&& ovsdb_idl_row_is_orphan(arc->dst)
|
2016-03-25 14:10:22 -07:00
|
|
|
|
&& ovs_list_is_empty(&arc->dst->dst_arcs)) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_row_destroy(arc->dst);
|
|
|
|
|
}
|
|
|
|
|
free(arc);
|
|
|
|
|
}
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_init(&row->src_arcs);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Force nodes that reference 'row' to reparse. */
|
|
|
|
|
static void
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_reparse_backrefs(struct ovsdb_idl_row *row)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_arc *arc, *next;
|
|
|
|
|
|
|
|
|
|
/* This is trickier than it looks. ovsdb_idl_row_clear_arcs() will destroy
|
|
|
|
|
* 'arc', so we need to use the "safe" variant of list traversal. However,
|
2010-01-25 10:15:17 -08:00
|
|
|
|
* calling an ovsdb_idl_column's 'parse' function will add an arc
|
|
|
|
|
* equivalent to 'arc' to row->arcs. That could be a problem for
|
|
|
|
|
* traversal, but it adds it at the beginning of the list to prevent us
|
|
|
|
|
* from stumbling upon it again.
|
2009-12-02 11:26:15 -08:00
|
|
|
|
*
|
|
|
|
|
* (If duplicate arcs were possible then we would need to make sure that
|
|
|
|
|
* 'next' didn't also point into 'arc''s destination, but we forbid
|
|
|
|
|
* duplicate arcs.) */
|
2010-09-17 10:33:10 -07:00
|
|
|
|
LIST_FOR_EACH_SAFE (arc, next, dst_node, &row->dst_arcs) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_row *ref = arc->src;
|
|
|
|
|
|
2010-01-25 10:15:17 -08:00
|
|
|
|
ovsdb_idl_row_unparse(ref);
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_clear_arcs(ref, false);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
ovsdb_idl_row_parse(ref);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_track_change(struct ovsdb_idl_row *row,
|
|
|
|
|
enum ovsdb_idl_change change)
|
|
|
|
|
{
|
|
|
|
|
row->change_seqno[change]
|
|
|
|
|
= row->table->change_seqno[change]
|
|
|
|
|
= row->table->idl->change_seqno + 1;
|
|
|
|
|
if (ovs_list_is_empty(&row->track_node)) {
|
|
|
|
|
ovs_list_push_back(&row->table->track_list, &row->track_node);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_untrack_change(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
if (ovs_list_is_empty(&row->track_node)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
row->change_seqno[OVSDB_IDL_CHANGE_INSERT] =
|
|
|
|
|
row->change_seqno[OVSDB_IDL_CHANGE_MODIFY] =
|
|
|
|
|
row->change_seqno[OVSDB_IDL_CHANGE_DELETE] = 0;
|
|
|
|
|
ovs_list_remove(&row->track_node);
|
|
|
|
|
ovs_list_init(&row->track_node);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_row_create__(const struct ovsdb_idl_table_class *class)
|
|
|
|
|
{
|
2009-12-08 17:14:36 -08:00
|
|
|
|
struct ovsdb_idl_row *row = xzalloc(class->allocation_size);
|
2012-05-22 01:53:07 -07:00
|
|
|
|
class->row_init(row);
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_init(&row->src_arcs);
|
|
|
|
|
ovs_list_init(&row->dst_arcs);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
hmap_node_nullify(&row->txn_node);
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_init(&row->track_node);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_row_create(struct ovsdb_idl_table *table, const struct uuid *uuid)
|
|
|
|
|
{
|
2017-08-11 11:06:44 -07:00
|
|
|
|
struct ovsdb_idl_row *row = ovsdb_idl_row_create__(table->class_);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
hmap_insert(&table->rows, &row->hmap_node, uuid_hash(uuid));
|
|
|
|
|
row->uuid = *uuid;
|
|
|
|
|
row->table = table;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
row->map_op_written = NULL;
|
|
|
|
|
row->map_op_lists = NULL;
|
2016-08-06 17:46:29 -05:00
|
|
|
|
row->set_op_written = NULL;
|
|
|
|
|
row->set_op_lists = NULL;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
/* If 'row' is not referenced anymore, removes 'row' from the table hmap,
|
|
|
|
|
* clears the old datum and adds 'row' to the table's track_list.
|
|
|
|
|
*
|
|
|
|
|
* If 'row' is still referenced, i.e., became "orphan", queues 'row' for
|
|
|
|
|
* reparsing after all updates have been processed by adding it to the
|
|
|
|
|
* 'deleted_untracked_rows' list.
|
|
|
|
|
*/
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_destroy(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
ovsdb_idl_row_clear_old(row);
|
|
|
|
|
if (ovs_list_is_empty(&row->dst_arcs)) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
hmap_remove(&row->table->rows, &row->hmap_node);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
ovsdb_idl_destroy_all_map_op_lists(row);
|
2016-08-06 17:46:29 -05:00
|
|
|
|
ovsdb_idl_destroy_all_set_op_lists(row);
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
ovsdb_idl_row_track_change(row, OVSDB_IDL_CHANGE_DELETE);
|
|
|
|
|
} else {
|
|
|
|
|
ovsdb_idl_row_untrack_change(row);
|
|
|
|
|
ovs_list_push_back(&row->table->idl->deleted_untracked_rows,
|
|
|
|
|
&row->track_node);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_destroy_all_map_op_lists(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
if (row->map_op_written) {
|
|
|
|
|
/* Clear Map Operation Lists */
|
|
|
|
|
size_t idx, n_columns;
|
|
|
|
|
const struct ovsdb_idl_column *columns;
|
|
|
|
|
const struct ovsdb_type *type;
|
2017-08-11 11:06:44 -07:00
|
|
|
|
n_columns = row->table->class_->n_columns;
|
|
|
|
|
columns = row->table->class_->columns;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
BITMAP_FOR_EACH_1 (idx, n_columns, row->map_op_written) {
|
|
|
|
|
type = &columns[idx].type;
|
|
|
|
|
map_op_list_destroy(row->map_op_lists[idx], type);
|
|
|
|
|
}
|
|
|
|
|
free(row->map_op_lists);
|
|
|
|
|
bitmap_free(row->map_op_written);
|
|
|
|
|
row->map_op_lists = NULL;
|
|
|
|
|
row->map_op_written = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_destroy_all_set_op_lists(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
if (row->set_op_written) {
|
|
|
|
|
/* Clear Set Operation Lists */
|
|
|
|
|
size_t idx, n_columns;
|
|
|
|
|
const struct ovsdb_idl_column *columns;
|
|
|
|
|
const struct ovsdb_type *type;
|
2017-08-11 11:06:44 -07:00
|
|
|
|
n_columns = row->table->class_->n_columns;
|
|
|
|
|
columns = row->table->class_->columns;
|
2016-08-06 17:46:29 -05:00
|
|
|
|
BITMAP_FOR_EACH_1 (idx, n_columns, row->set_op_written) {
|
|
|
|
|
type = &columns[idx].type;
|
|
|
|
|
set_op_list_destroy(row->set_op_lists[idx], type);
|
|
|
|
|
}
|
|
|
|
|
free(row->set_op_lists);
|
|
|
|
|
bitmap_free(row->set_op_written);
|
|
|
|
|
row->set_op_lists = NULL;
|
|
|
|
|
row->set_op_written = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
static void
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_row_destroy_postprocess(struct ovsdb_idl *idl)
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
for (size_t i = 0; i < idl->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &idl->tables[i];
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
2016-03-25 14:10:22 -07:00
|
|
|
|
if (!ovs_list_is_empty(&table->track_list)) {
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
struct ovsdb_idl_row *row, *next;
|
|
|
|
|
|
|
|
|
|
LIST_FOR_EACH_SAFE(row, next, track_node, &table->track_list) {
|
|
|
|
|
if (!ovsdb_idl_track_is_set(row->table)) {
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_remove(&row->track_node);
|
2019-05-17 12:56:33 -07:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
free(row);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2020-12-01 18:15:11 -08:00
|
|
|
|
ovsdb_idl_insert_row(struct ovsdb_idl_row *row, const struct shash *data)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2017-08-11 11:06:47 -07:00
|
|
|
|
size_t i, datum_size;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovs_assert(!row->old_datum && !row->new_datum);
|
|
|
|
|
datum_size = class->n_columns * sizeof *row->old_datum;
|
|
|
|
|
row->old_datum = row->new_datum = xmalloc(datum_size);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
for (i = 0; i < class->n_columns; i++) {
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovsdb_datum_init_default(&row->old_datum[i], &class->columns[i].type);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2020-12-01 18:15:11 -08:00
|
|
|
|
ovsdb_idl_row_change(row, data, false, OVSDB_IDL_CHANGE_INSERT);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
ovsdb_idl_row_parse(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_reparse_backrefs(row);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_delete_row(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-03 14:20:15 -04:00
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_row_clear_arcs(row, true);
|
ovsdb-idl: Preserve references for deleted rows.
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are present in the IDL client's in-memory view of
the database, depending whether row 'b' is also deleted in the same
transaction or not, deletion of row 'a' should generate the following
tracked changes:
1. only row 'a' is deleted:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- updated records: b = {B._uuid=<U2>, B.ref_a=[]}
2. row 'a' and row 'b' are deleted in the same update:
- for table A:
- deleted records: a = {A._uuid=<U1>}
- for table B:
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
To ensure this, we now delay reparsing row backrefs for deleted rows
until all updates in the current run have been processed.
Without this change, in scenario 2 above, the tracked changes for table
B would be:
- deleted records: b = {B._uuid=<U2>, B.ref_a=[]}
In particular, for strong references, row 'a' can never be deleted in
a transaction that happens strictly before row 'b' is deleted. In some
cases [0] both rows are deleted in the same transaction and having
B.ref_a=[] would violate the integrity of the database from client
perspective. This would force the client to always validate that
strong reference fields are non-NULL. This is not really an option
because the information in the original reference is required for
incrementally processing the record deletion.
[0] with ovn-monitor-all=true, the following command triggers a crash
in ovn-controller because a strong reference field becomes NULL:
$ ovn-nbctl --wait=hv -- lr-add r -- lrp-add r rp 00:00:00:00:00:01 1.0.0.1/24
$ ovn-nbctl lr-del r
Reported-at: https://bugzilla.redhat.com/1932642
Fixes: 72aeb243a52a ("ovsdb-idl: Tracking - preserve data for deleted rows.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-03-24 10:33:22 +01:00
|
|
|
|
ovsdb_idl_row_destroy(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-08-11 15:41:41 -07:00
|
|
|
|
/* Returns true if a column with mode OVSDB_IDL_MODE_RW changed, false
|
|
|
|
|
* otherwise. */
|
|
|
|
|
static bool
|
2020-12-01 18:15:11 -08:00
|
|
|
|
ovsdb_idl_modify_row(struct ovsdb_idl_row *row, const struct shash *values,
|
|
|
|
|
bool xor)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
2018-08-10 20:29:46 -07:00
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
|
|
|
|
ovsdb_idl_row_clear_arcs(row, true);
|
2020-12-01 18:15:11 -08:00
|
|
|
|
bool changed = ovsdb_idl_row_change(row, values, xor,
|
|
|
|
|
OVSDB_IDL_CHANGE_MODIFY);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
ovsdb_idl_row_parse(row);
|
2018-08-10 20:29:46 -07:00
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
|
|
|
|
|
return changed;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static bool
|
|
|
|
|
may_add_arc(const struct ovsdb_idl_row *src, const struct ovsdb_idl_row *dst)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_arc *arc;
|
|
|
|
|
|
|
|
|
|
/* No self-arcs. */
|
|
|
|
|
if (src == dst) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* No duplicate arcs.
|
|
|
|
|
*
|
|
|
|
|
* We only need to test whether the first arc in dst->dst_arcs originates
|
|
|
|
|
* at 'src', since we add all of the arcs from a given source in a clump
|
2010-01-25 10:15:17 -08:00
|
|
|
|
* (in a single call to ovsdb_idl_row_parse()) and new arcs are always
|
2009-12-02 11:26:15 -08:00
|
|
|
|
* added at the front of the dst_arcs list. */
|
2016-03-25 14:10:22 -07:00
|
|
|
|
if (ovs_list_is_empty(&dst->dst_arcs)) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
arc = CONTAINER_OF(dst->dst_arcs.next, struct ovsdb_idl_arc, dst_node);
|
|
|
|
|
return arc->src != src;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-04 14:55:24 -08:00
|
|
|
|
static struct ovsdb_idl_table *
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_table_from_class(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *table_class)
|
2009-12-04 14:55:24 -08:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ptrdiff_t idx = table_class - idl->class_->tables;
|
|
|
|
|
return idx >= 0 && idx < idl->class_->n_tables ? &idl->tables[idx] : NULL;
|
2009-12-04 14:55:24 -08:00
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Called by ovsdb-idlc generated code. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_get_row_arc(struct ovsdb_idl_row *src,
|
2016-08-24 23:10:15 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *dst_table_class,
|
2009-12-02 11:26:15 -08:00
|
|
|
|
const struct uuid *dst_uuid)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovsdb_idl *idl = src->table->idl;
|
2009-12-03 10:35:45 -08:00
|
|
|
|
struct ovsdb_idl_table *dst_table;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_arc *arc;
|
|
|
|
|
struct ovsdb_idl_row *dst;
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
dst_table = ovsdb_idl_table_from_class(idl, dst_table_class);
|
2009-12-03 10:35:45 -08:00
|
|
|
|
dst = ovsdb_idl_get_row(dst_table, dst_uuid);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
if (idl->txn || is_index_row(src)) {
|
2017-10-30 12:21:49 -07:00
|
|
|
|
/* There are two cases we should not update any arcs:
|
|
|
|
|
*
|
|
|
|
|
* 1. We're being called from ovsdb_idl_txn_write(). We must not update
|
2010-01-25 10:15:17 -08:00
|
|
|
|
* any arcs, because the transaction will be backed out at commit or
|
|
|
|
|
* abort time and we don't want our graph screwed up.
|
|
|
|
|
*
|
2017-10-30 12:21:49 -07:00
|
|
|
|
* 2. The row is used as an index for querying purpose only.
|
|
|
|
|
*
|
|
|
|
|
* In these cases, just return the destination row, if there is one and
|
|
|
|
|
* it has not been deleted. */
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (dst && (hmap_node_is_null(&dst->txn_node) || dst->new_datum)) {
|
2010-01-25 10:15:17 -08:00
|
|
|
|
return dst;
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
} else {
|
|
|
|
|
/* We're being called from some other context. Update the graph. */
|
|
|
|
|
if (!dst) {
|
|
|
|
|
dst = ovsdb_idl_row_create(dst_table, dst_uuid);
|
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2010-01-25 10:15:17 -08:00
|
|
|
|
/* Add a new arc, if it wouldn't be a self-arc or a duplicate arc. */
|
|
|
|
|
if (may_add_arc(src, dst)) {
|
|
|
|
|
/* The arc *must* be added at the front of the dst_arcs list. See
|
|
|
|
|
* ovsdb_idl_row_reparse_backrefs() for details. */
|
|
|
|
|
arc = xmalloc(sizeof *arc);
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_push_front(&src->src_arcs, &arc->src_node);
|
|
|
|
|
ovs_list_push_front(&dst->dst_arcs, &arc->dst_node);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
arc->src = src;
|
|
|
|
|
arc->dst = dst;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return !ovsdb_idl_row_is_orphan(dst) ? dst : NULL;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2010-01-25 10:15:17 -08:00
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Searches 'tc''s table in 'idl' for a row with UUID 'uuid'. Returns a
|
|
|
|
|
* pointer to the row if there is one, otherwise a null pointer. */
|
2010-01-25 10:15:17 -08:00
|
|
|
|
const struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_get_row_for_uuid(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *tc,
|
|
|
|
|
const struct uuid *uuid)
|
|
|
|
|
{
|
|
|
|
|
return ovsdb_idl_get_row(ovsdb_idl_table_from_class(idl, tc), uuid);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct ovsdb_idl_row *
|
|
|
|
|
next_real_row(struct ovsdb_idl_table *table, struct hmap_node *node)
|
|
|
|
|
{
|
|
|
|
|
for (; node; node = hmap_next(&table->rows, node)) {
|
|
|
|
|
struct ovsdb_idl_row *row;
|
|
|
|
|
|
|
|
|
|
row = CONTAINER_OF(node, struct ovsdb_idl_row, hmap_node);
|
2010-03-03 09:59:47 -08:00
|
|
|
|
if (ovsdb_idl_row_exists(row)) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns a row in 'table_class''s table in 'idl', or a null pointer if that
|
|
|
|
|
* table is empty.
|
|
|
|
|
*
|
|
|
|
|
* Database tables are internally maintained as hash tables, so adding or
|
|
|
|
|
* removing rows while traversing the same table can cause some rows to be
|
|
|
|
|
* visited twice or not at apply. */
|
2010-01-25 10:15:17 -08:00
|
|
|
|
const struct ovsdb_idl_row *
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_first_row(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *table_class)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_table *table = ovsdb_idl_table_from_class(idl,
|
|
|
|
|
table_class);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
return next_real_row(table, hmap_first(&table->rows));
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns a row following 'row' within its table, or a null pointer if 'row'
|
|
|
|
|
* is the last row in its table. */
|
2010-01-25 10:15:17 -08:00
|
|
|
|
const struct ovsdb_idl_row *
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_next_row(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table = row->table;
|
|
|
|
|
|
|
|
|
|
return next_real_row(table, hmap_next(&table->rows, &row->hmap_node));
|
|
|
|
|
}
|
2010-06-16 14:35:48 -07:00
|
|
|
|
|
|
|
|
|
/* Reads and returns the value of 'column' within 'row'. If an ongoing
|
|
|
|
|
* transaction has changed 'column''s value, the modified value is returned.
|
|
|
|
|
*
|
|
|
|
|
* The caller must not modify or free the returned value.
|
|
|
|
|
*
|
|
|
|
|
* Various kinds of changes can invalidate the returned value: writing to the
|
|
|
|
|
* same 'column' in 'row' (e.g. with ovsdb_idl_txn_write()), deleting 'row'
|
|
|
|
|
* (e.g. with ovsdb_idl_txn_delete()), or completing an ongoing transaction
|
|
|
|
|
* (e.g. with ovsdb_idl_txn_commit() or ovsdb_idl_txn_abort()). If the
|
|
|
|
|
* returned value is needed for a long time, it is best to make a copy of it
|
|
|
|
|
* with ovsdb_datum_clone(). */
|
|
|
|
|
const struct ovsdb_datum *
|
|
|
|
|
ovsdb_idl_read(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2011-11-15 13:59:41 -08:00
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
|
|
|
|
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(!ovsdb_idl_row_is_synthetic(row));
|
2011-11-15 13:59:41 -08:00
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
2011-11-15 13:59:41 -08:00
|
|
|
|
column_idx = column - class->columns;
|
2010-06-16 14:35:48 -07:00
|
|
|
|
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovs_assert(row->new_datum != NULL);
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(column_idx < class->n_columns);
|
2010-06-16 14:35:48 -07:00
|
|
|
|
|
|
|
|
|
if (row->written && bitmap_is_set(row->written, column_idx)) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
return &row->new_datum[column_idx];
|
2017-08-11 11:06:47 -07:00
|
|
|
|
} else if (row->old_datum) {
|
|
|
|
|
return &row->old_datum[column_idx];
|
2010-06-16 14:35:48 -07:00
|
|
|
|
} else {
|
|
|
|
|
return ovsdb_datum_default(&column->type);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Same as ovsdb_idl_read(), except that it also asserts that 'column' has key
|
|
|
|
|
* type 'key_type' and value type 'value_type'. (Scalar and set types will
|
|
|
|
|
* have a value type of OVSDB_TYPE_VOID.)
|
|
|
|
|
*
|
|
|
|
|
* This is useful in code that "knows" that a particular column has a given
|
|
|
|
|
* type, so that it will abort if someone changes the column's type without
|
|
|
|
|
* updating the code that uses it. */
|
|
|
|
|
const struct ovsdb_datum *
|
|
|
|
|
ovsdb_idl_get(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
enum ovsdb_atomic_type key_type OVS_UNUSED,
|
|
|
|
|
enum ovsdb_atomic_type value_type OVS_UNUSED)
|
|
|
|
|
{
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(column->type.key.type == key_type);
|
|
|
|
|
ovs_assert(column->type.value.type == value_type);
|
2010-06-16 14:35:48 -07:00
|
|
|
|
|
|
|
|
|
return ovsdb_idl_read(row, column);
|
|
|
|
|
}
|
2011-04-13 11:10:44 -07:00
|
|
|
|
|
2014-09-26 16:00:44 -07:00
|
|
|
|
/* Returns true if the field represented by 'column' in 'row' may be modified,
|
|
|
|
|
* false if it is immutable.
|
|
|
|
|
*
|
|
|
|
|
* Normally, whether a field is mutable is controlled by its column's schema.
|
|
|
|
|
* However, an immutable column can be set to any initial value at the time of
|
|
|
|
|
* insertion, so if 'row' is a new row (one that is being added as part of the
|
|
|
|
|
* current transaction, supposing that a transaction is in progress) then even
|
|
|
|
|
* its "immutable" fields are actually mutable. */
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_is_mutable(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2017-08-11 11:06:47 -07:00
|
|
|
|
return column->is_mutable || (row->new_datum && !row->old_datum);
|
2014-09-26 16:00:44 -07:00
|
|
|
|
}
|
|
|
|
|
|
2011-04-13 11:10:44 -07:00
|
|
|
|
/* Returns false if 'row' was obtained from the IDL, true if it was initialized
|
|
|
|
|
* to all-zero-bits by some other entity. If 'row' was set up some other way
|
|
|
|
|
* then the return value is indeterminate. */
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_row_is_synthetic(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
return row->table == NULL;
|
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
|
|
|
|
/* Transactions. */
|
|
|
|
|
|
|
|
|
|
static void ovsdb_idl_txn_complete(struct ovsdb_idl_txn *txn,
|
|
|
|
|
enum ovsdb_idl_txn_status);
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns a string representation of 'status'. The caller must not modify or
|
|
|
|
|
* free the returned string.
|
|
|
|
|
*
|
|
|
|
|
* The return value is probably useful only for debug log messages and unit
|
|
|
|
|
* tests. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
const char *
|
|
|
|
|
ovsdb_idl_txn_status_to_string(enum ovsdb_idl_txn_status status)
|
|
|
|
|
{
|
|
|
|
|
switch (status) {
|
2011-06-20 16:17:44 -07:00
|
|
|
|
case TXN_UNCOMMITTED:
|
|
|
|
|
return "uncommitted";
|
2009-12-16 16:26:17 -08:00
|
|
|
|
case TXN_UNCHANGED:
|
|
|
|
|
return "unchanged";
|
2009-12-07 17:08:04 -08:00
|
|
|
|
case TXN_INCOMPLETE:
|
|
|
|
|
return "incomplete";
|
|
|
|
|
case TXN_ABORTED:
|
|
|
|
|
return "aborted";
|
|
|
|
|
case TXN_SUCCESS:
|
|
|
|
|
return "success";
|
2012-03-27 10:16:52 -07:00
|
|
|
|
case TXN_TRY_AGAIN:
|
|
|
|
|
return "try again";
|
2011-07-26 16:49:03 -07:00
|
|
|
|
case TXN_NOT_LOCKED:
|
|
|
|
|
return "not locked";
|
2009-12-07 17:08:04 -08:00
|
|
|
|
case TXN_ERROR:
|
|
|
|
|
return "error";
|
|
|
|
|
}
|
|
|
|
|
return "<unknown>";
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Starts a new transaction on 'idl'. A given ovsdb_idl may only have a single
|
|
|
|
|
* active transaction at a time. See the large comment in ovsdb-idl.h for
|
|
|
|
|
* general information on transactions. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
struct ovsdb_idl_txn *
|
|
|
|
|
ovsdb_idl_txn_create(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_txn *txn;
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovs_assert(!idl->txn);
|
|
|
|
|
idl->txn = txn = xmalloc(sizeof *txn);
|
2010-02-02 14:03:18 -08:00
|
|
|
|
txn->request_id = NULL;
|
2020-11-21 11:47:01 -08:00
|
|
|
|
txn->idl = idl;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
hmap_init(&txn->txn_rows);
|
2011-06-20 16:17:44 -07:00
|
|
|
|
txn->status = TXN_UNCOMMITTED;
|
2010-02-05 14:11:12 -08:00
|
|
|
|
txn->error = NULL;
|
2009-12-11 11:28:36 -08:00
|
|
|
|
txn->dry_run = false;
|
2009-12-16 13:30:53 -08:00
|
|
|
|
ds_init(&txn->comment);
|
2010-02-02 14:03:18 -08:00
|
|
|
|
|
2009-12-16 16:26:17 -08:00
|
|
|
|
txn->inc_table = NULL;
|
|
|
|
|
txn->inc_column = NULL;
|
2010-02-02 14:03:18 -08:00
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
hmap_init(&txn->inserted_rows);
|
2010-02-02 14:03:18 -08:00
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
return txn;
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-08 14:18:44 -08:00
|
|
|
|
/* Appends 's', which is treated as a printf()-type format string, to the
|
|
|
|
|
* comments that will be passed to the OVSDB server when 'txn' is committed.
|
|
|
|
|
* (The comment will be committed to the OVSDB log, which "ovsdb-tool
|
|
|
|
|
* show-log" can print in a relatively human-readable form.) */
|
2009-12-16 13:30:53 -08:00
|
|
|
|
void
|
2010-03-08 14:18:44 -08:00
|
|
|
|
ovsdb_idl_txn_add_comment(struct ovsdb_idl_txn *txn, const char *s, ...)
|
2009-12-16 13:30:53 -08:00
|
|
|
|
{
|
2010-03-08 14:18:44 -08:00
|
|
|
|
va_list args;
|
|
|
|
|
|
2009-12-16 13:30:53 -08:00
|
|
|
|
if (txn->comment.length) {
|
|
|
|
|
ds_put_char(&txn->comment, '\n');
|
|
|
|
|
}
|
2010-03-08 14:18:44 -08:00
|
|
|
|
|
|
|
|
|
va_start(args, s);
|
|
|
|
|
ds_put_format_valist(&txn->comment, s, args);
|
|
|
|
|
va_end(args);
|
2009-12-16 13:30:53 -08:00
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Marks 'txn' as a transaction that will not actually modify the database. In
|
|
|
|
|
* almost every way, the transaction is treated like other transactions. It
|
|
|
|
|
* must be committed or aborted like other transactions, it will be sent to the
|
|
|
|
|
* database server like other transactions, and so on. The only difference is
|
|
|
|
|
* that the operations sent to the database server will include, as the last
|
|
|
|
|
* step, an "abort" operation, so that any changes made by the transaction will
|
|
|
|
|
* not actually take effect. */
|
2009-12-11 11:28:36 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_set_dry_run(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
txn->dry_run = true;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:25:10 -07:00
|
|
|
|
/* Causes 'txn', when committed, to increment the value of 'column' within
|
|
|
|
|
* 'row' by 1. 'column' must have an integer type. After 'txn' commits
|
|
|
|
|
* successfully, the client may retrieve the final (incremented) value of
|
|
|
|
|
* 'column' with ovsdb_idl_txn_get_increment_new_value().
|
|
|
|
|
*
|
2016-08-07 20:44:51 -07:00
|
|
|
|
* If at time of commit the transaction is otherwise empty, that is, it doesn't
|
|
|
|
|
* change the database, then 'force' is important. If 'force' is false in this
|
|
|
|
|
* case, the IDL suppresses the increment and skips a round trip to the
|
|
|
|
|
* database server. If 'force' is true, the IDL will still increment the
|
|
|
|
|
* column.
|
|
|
|
|
*
|
2012-04-12 08:25:10 -07:00
|
|
|
|
* The client could accomplish something similar with ovsdb_idl_read(),
|
|
|
|
|
* ovsdb_idl_txn_verify() and ovsdb_idl_txn_write(), or with ovsdb-idlc
|
|
|
|
|
* generated wrappers for these functions. However, ovsdb_idl_txn_increment()
|
|
|
|
|
* will never (by itself) fail because of a verify error.
|
|
|
|
|
*
|
|
|
|
|
* The intended use is for incrementing the "next_cfg" column in the
|
|
|
|
|
* Open_vSwitch table. */
|
2009-12-16 16:26:17 -08:00
|
|
|
|
void
|
2012-04-12 08:25:10 -07:00
|
|
|
|
ovsdb_idl_txn_increment(struct ovsdb_idl_txn *txn,
|
|
|
|
|
const struct ovsdb_idl_row *row,
|
2016-08-07 20:44:51 -07:00
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
bool force)
|
2009-12-16 16:26:17 -08:00
|
|
|
|
{
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(!txn->inc_table);
|
|
|
|
|
ovs_assert(column->type.key.type == OVSDB_TYPE_INTEGER);
|
|
|
|
|
ovs_assert(column->type.value.type == OVSDB_TYPE_VOID);
|
2012-04-12 08:25:10 -07:00
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
txn->inc_table = row->table->class_->name;
|
2012-04-12 08:25:10 -07:00
|
|
|
|
txn->inc_column = column->name;
|
|
|
|
|
txn->inc_row = row->uuid;
|
2016-08-07 20:44:51 -07:00
|
|
|
|
txn->inc_force = force;
|
2009-12-16 16:26:17 -08:00
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Destroys 'txn' and frees all associated memory. If ovsdb_idl_txn_commit()
|
|
|
|
|
* has been called for 'txn' but the commit is still incomplete (that is, the
|
|
|
|
|
* last call returned TXN_INCOMPLETE) then the transaction may or may not still
|
|
|
|
|
* end up committing at the database server, but the client will not be able to
|
|
|
|
|
* get any further status information back. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_destroy(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
2010-01-28 13:23:30 -08:00
|
|
|
|
struct ovsdb_idl_txn_insert *insert, *next;
|
|
|
|
|
|
2009-12-11 16:58:16 -08:00
|
|
|
|
if (txn->status == TXN_INCOMPLETE) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_forget_transaction(txn->idl->cs, txn->request_id);
|
|
|
|
|
hmap_remove(&txn->idl->outstanding_txns, &txn->hmap_node);
|
2009-12-11 16:58:16 -08:00
|
|
|
|
}
|
2020-11-21 11:47:01 -08:00
|
|
|
|
json_destroy(txn->request_id);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_txn_abort(txn);
|
2009-12-16 13:30:53 -08:00
|
|
|
|
ds_destroy(&txn->comment);
|
2010-02-05 14:11:12 -08:00
|
|
|
|
free(txn->error);
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_SAFE (insert, next, hmap_node, &txn->inserted_rows) {
|
2010-01-28 13:23:30 -08:00
|
|
|
|
free(insert);
|
|
|
|
|
}
|
2010-02-02 14:03:18 -08:00
|
|
|
|
hmap_destroy(&txn->inserted_rows);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
free(txn);
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Causes poll_block() to wake up if 'txn' has completed committing. */
|
2009-12-09 13:29:02 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_wait(const struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
2011-06-20 16:17:44 -07:00
|
|
|
|
if (txn->status != TXN_UNCOMMITTED && txn->status != TXN_INCOMPLETE) {
|
2009-12-09 13:29:02 -08:00
|
|
|
|
poll_immediate_wake();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static struct json *
|
|
|
|
|
where_uuid_equals(const struct uuid *uuid)
|
|
|
|
|
{
|
|
|
|
|
return
|
|
|
|
|
json_array_create_1(
|
|
|
|
|
json_array_create_3(
|
|
|
|
|
json_string_create("_uuid"),
|
|
|
|
|
json_string_create("=="),
|
|
|
|
|
json_array_create_2(
|
|
|
|
|
json_string_create("uuid"),
|
|
|
|
|
json_string_create_nocopy(
|
|
|
|
|
xasprintf(UUID_FMT, UUID_ARGS(uuid))))));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_txn_get_row(const struct ovsdb_idl_txn *txn, const struct uuid *uuid)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_row *row;
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_WITH_HASH (row, txn_node, uuid_hash(uuid), &txn->txn_rows) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (uuid_equals(&row->uuid, uuid)) {
|
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* XXX there must be a cleaner way to do this */
|
|
|
|
|
static struct json *
|
|
|
|
|
substitute_uuids(struct json *json, const struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
if (json->type == JSON_ARRAY) {
|
|
|
|
|
struct uuid uuid;
|
|
|
|
|
size_t i;
|
|
|
|
|
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (json->array.n == 2
|
|
|
|
|
&& json->array.elems[0]->type == JSON_STRING
|
|
|
|
|
&& json->array.elems[1]->type == JSON_STRING
|
|
|
|
|
&& !strcmp(json->array.elems[0]->string, "uuid")
|
|
|
|
|
&& uuid_from_string(&uuid, json->array.elems[1]->string)) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
const struct ovsdb_idl_row *row;
|
|
|
|
|
|
|
|
|
|
row = ovsdb_idl_txn_get_row(txn, &uuid);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (row && !row->old_datum && row->new_datum) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
json_destroy(json);
|
|
|
|
|
|
|
|
|
|
return json_array_create_2(
|
|
|
|
|
json_string_create("named-uuid"),
|
2017-12-21 16:41:30 -08:00
|
|
|
|
json_string_create_nocopy(ovsdb_data_row_name(&uuid)));
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-24 10:32:59 -07:00
|
|
|
|
for (i = 0; i < json->array.n; i++) {
|
|
|
|
|
json->array.elems[i] = substitute_uuids(json->array.elems[i],
|
2009-12-07 17:08:04 -08:00
|
|
|
|
txn);
|
|
|
|
|
}
|
|
|
|
|
} else if (json->type == JSON_OBJECT) {
|
|
|
|
|
struct shash_node *node;
|
|
|
|
|
|
|
|
|
|
SHASH_FOR_EACH (node, json_object(json)) {
|
|
|
|
|
node->data = substitute_uuids(node->data, txn);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return json;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_disassemble(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row, *next;
|
|
|
|
|
|
2010-01-25 10:15:17 -08:00
|
|
|
|
/* This must happen early. Otherwise, ovsdb_idl_row_parse() will call an
|
|
|
|
|
* ovsdb_idl_column's 'parse' function, which will call
|
|
|
|
|
* ovsdb_idl_get_row_arc(), which will seen that the IDL is in a
|
|
|
|
|
* transaction and fail to update the graph. */
|
2020-11-21 11:47:01 -08:00
|
|
|
|
txn->idl->txn = NULL;
|
2010-01-25 10:15:17 -08:00
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_SAFE (row, next, txn_node, &txn->txn_rows) {
|
2018-08-14 11:31:46 -07:00
|
|
|
|
enum { INSERTED, MODIFIED, DELETED } op
|
|
|
|
|
= (!row->new_datum ? DELETED
|
|
|
|
|
: !row->old_datum ? INSERTED
|
|
|
|
|
: MODIFIED);
|
|
|
|
|
|
|
|
|
|
if (op != DELETED) {
|
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
ovsdb_idl_destroy_all_map_op_lists(row);
|
2016-08-06 17:46:29 -05:00
|
|
|
|
ovsdb_idl_destroy_all_set_op_lists(row);
|
2018-08-14 11:31:46 -07:00
|
|
|
|
if (op != INSERTED) {
|
2010-01-25 10:15:17 -08:00
|
|
|
|
if (row->written) {
|
|
|
|
|
ovsdb_idl_row_unparse(row);
|
|
|
|
|
ovsdb_idl_row_clear_arcs(row, false);
|
|
|
|
|
ovsdb_idl_row_parse(row);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
2009-12-08 09:48:37 -08:00
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_row_clear_new(row);
|
|
|
|
|
|
|
|
|
|
free(row->prereqs);
|
|
|
|
|
row->prereqs = NULL;
|
|
|
|
|
|
|
|
|
|
free(row->written);
|
|
|
|
|
row->written = NULL;
|
|
|
|
|
|
|
|
|
|
hmap_remove(&txn->txn_rows, &row->txn_node);
|
|
|
|
|
hmap_node_nullify(&row->txn_node);
|
2018-08-14 11:31:46 -07:00
|
|
|
|
if (op != INSERTED) {
|
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
|
|
|
|
} else {
|
2010-02-02 14:03:18 -08:00
|
|
|
|
hmap_remove(&row->table->rows, &row->hmap_node);
|
|
|
|
|
free(row);
|
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
hmap_destroy(&txn->txn_rows);
|
|
|
|
|
hmap_init(&txn->txn_rows);
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_txn_extract_mutations(struct ovsdb_idl_row *row,
|
|
|
|
|
struct json *mutations)
|
|
|
|
|
{
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
size_t idx;
|
|
|
|
|
bool any_mutations = false;
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
if (row->map_op_written) {
|
|
|
|
|
BITMAP_FOR_EACH_1(idx, class->n_columns, row->map_op_written) {
|
|
|
|
|
struct map_op_list *map_op_list;
|
|
|
|
|
const struct ovsdb_idl_column *column;
|
|
|
|
|
const struct ovsdb_datum *old_datum;
|
|
|
|
|
enum ovsdb_atomic_type key_type, value_type;
|
|
|
|
|
struct json *mutation, *map, *col_name, *mutator;
|
|
|
|
|
struct json *del_set, *ins_map;
|
|
|
|
|
bool any_del, any_ins;
|
|
|
|
|
|
|
|
|
|
map_op_list = row->map_op_lists[idx];
|
|
|
|
|
column = &class->columns[idx];
|
|
|
|
|
key_type = column->type.key.type;
|
|
|
|
|
value_type = column->type.value.type;
|
|
|
|
|
|
|
|
|
|
/* Get the value to be changed */
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (row->new_datum && row->written
|
|
|
|
|
&& bitmap_is_set(row->written,idx)) {
|
|
|
|
|
old_datum = &row->new_datum[idx];
|
2017-08-11 11:06:47 -07:00
|
|
|
|
} else if (row->old_datum != NULL) {
|
|
|
|
|
old_datum = &row->old_datum[idx];
|
2016-08-06 17:46:29 -05:00
|
|
|
|
} else {
|
|
|
|
|
old_datum = ovsdb_datum_default(&column->type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
del_set = json_array_create_empty();
|
|
|
|
|
ins_map = json_array_create_empty();
|
|
|
|
|
any_del = false;
|
|
|
|
|
any_ins = false;
|
|
|
|
|
|
|
|
|
|
for (struct map_op *map_op = map_op_list_first(map_op_list); map_op;
|
|
|
|
|
map_op = map_op_list_next(map_op_list, map_op)) {
|
|
|
|
|
|
|
|
|
|
if (map_op_type(map_op) == MAP_OP_UPDATE) {
|
|
|
|
|
/* Find out if value really changed. */
|
|
|
|
|
struct ovsdb_datum *new_datum;
|
|
|
|
|
unsigned int pos;
|
|
|
|
|
new_datum = map_op_datum(map_op);
|
ovsdb-data: Optimize union of sets.
Current algorithm of ovsdb_datum_union looks like this:
for-each atom in b:
if not bin_search(a, atom):
push(a, clone(atom))
quicksort(a)
So, the complexity looks like this:
Nb * log2(Na) + Nb + (Na + Nb) * log2(Na + Nb)
Comparisons clones Comparisons for quicksort
for search
ovsdb_datum_union() is heavily used in database transactions while
new element is added to a set. For example, if new logical switch
port is added to a logical switch in OVN. This is a very common
use case where CMS adds one new port to an existing switch that
already has, let's say, 100 ports. For this case ovsdb-server will
have to perform:
1 * log2(100) + 1 clone + 101 * log2(101)
Comparisons Comparisons for
for search quicksort.
~7 1 ~707
Roughly 714 comparisons of atoms and 1 clone.
Since binary search can give us position, where new atom should go
(it's the 'low' index after the search completion) for free, the
logic can be re-worked like this:
copied = 0
for-each atom in b:
desired_position = bin_search(a, atom)
push(result, a[ copied : desired_position - 1 ])
copied = desired_position
push(result, clone(atom))
push(result, a[ copied : Na ])
swap(a, result)
Complexity of this schema:
Nb * log2(Na) + Nb + Na
Comparisons clones memory copy on push
for search
'swap' is just a swap of a few pointers. 'push' is not a 'clone',
but a simple memory copy of 'union ovsdb_atom'.
In general, this schema substitutes complexity of a quicksort
with complexity of a memory copy of Na atom structures, where we're
not even copying strings that these atoms are pointing to.
Complexity in the example above goes down from 714 comparisons
to 7 comparisons and memcpy of 100 * sizeof (union ovsdb_atom) bytes.
General complexity of a memory copy should always be lower than
complexity of a quicksort, especially because these copies usually
performed in bulk, so this new schema should work faster for any input.
All in all, this change allows to execute several times more
transactions per second for transactions that adds new entries to sets.
Alternatively, union can be implemented as a linear merge of two
sorted arrays, but this will result in O(Na) comparisons, which
is more than Nb * log2(Na) in common case, since Na is usually
far bigger than Nb. Linear merge will also mean per-atom memory
copies instead of copying in bulk.
'replace' functionality of ovsdb_datum_union() had no users, so it
just removed. But it can easily be added back if needed in the future.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Han Zhou <hzhou@ovn.org>
Acked-by: Mark D. Gray <mark.d.gray@redhat.com>
2021-09-23 01:47:22 +02:00
|
|
|
|
ovsdb_datum_find_key(old_datum, &new_datum->keys[0],
|
|
|
|
|
key_type, &pos);
|
2016-08-06 17:46:29 -05:00
|
|
|
|
if (ovsdb_atom_equals(&new_datum->values[0],
|
|
|
|
|
&old_datum->values[pos],
|
|
|
|
|
value_type)) {
|
|
|
|
|
/* No change in value. Move on to next update. */
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
} else if (map_op_type(map_op) == MAP_OP_DELETE){
|
|
|
|
|
/* Verify that there is a key to delete. */
|
ovsdb-data: Optimize union of sets.
Current algorithm of ovsdb_datum_union looks like this:
for-each atom in b:
if not bin_search(a, atom):
push(a, clone(atom))
quicksort(a)
So, the complexity looks like this:
Nb * log2(Na) + Nb + (Na + Nb) * log2(Na + Nb)
Comparisons clones Comparisons for quicksort
for search
ovsdb_datum_union() is heavily used in database transactions while
new element is added to a set. For example, if new logical switch
port is added to a logical switch in OVN. This is a very common
use case where CMS adds one new port to an existing switch that
already has, let's say, 100 ports. For this case ovsdb-server will
have to perform:
1 * log2(100) + 1 clone + 101 * log2(101)
Comparisons Comparisons for
for search quicksort.
~7 1 ~707
Roughly 714 comparisons of atoms and 1 clone.
Since binary search can give us position, where new atom should go
(it's the 'low' index after the search completion) for free, the
logic can be re-worked like this:
copied = 0
for-each atom in b:
desired_position = bin_search(a, atom)
push(result, a[ copied : desired_position - 1 ])
copied = desired_position
push(result, clone(atom))
push(result, a[ copied : Na ])
swap(a, result)
Complexity of this schema:
Nb * log2(Na) + Nb + Na
Comparisons clones memory copy on push
for search
'swap' is just a swap of a few pointers. 'push' is not a 'clone',
but a simple memory copy of 'union ovsdb_atom'.
In general, this schema substitutes complexity of a quicksort
with complexity of a memory copy of Na atom structures, where we're
not even copying strings that these atoms are pointing to.
Complexity in the example above goes down from 714 comparisons
to 7 comparisons and memcpy of 100 * sizeof (union ovsdb_atom) bytes.
General complexity of a memory copy should always be lower than
complexity of a quicksort, especially because these copies usually
performed in bulk, so this new schema should work faster for any input.
All in all, this change allows to execute several times more
transactions per second for transactions that adds new entries to sets.
Alternatively, union can be implemented as a linear merge of two
sorted arrays, but this will result in O(Na) comparisons, which
is more than Nb * log2(Na) in common case, since Na is usually
far bigger than Nb. Linear merge will also mean per-atom memory
copies instead of copying in bulk.
'replace' functionality of ovsdb_datum_union() had no users, so it
just removed. But it can easily be added back if needed in the future.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Han Zhou <hzhou@ovn.org>
Acked-by: Mark D. Gray <mark.d.gray@redhat.com>
2021-09-23 01:47:22 +02:00
|
|
|
|
if (!ovsdb_datum_find_key(old_datum,
|
|
|
|
|
&map_op_datum(map_op)->keys[0],
|
|
|
|
|
key_type, NULL)) {
|
2016-08-06 17:46:29 -05:00
|
|
|
|
/* No key to delete. Move on to next update. */
|
|
|
|
|
VLOG_WARN("Trying to delete a key that doesn't "
|
|
|
|
|
"exist in the map.");
|
|
|
|
|
continue;
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
}
|
2016-08-06 17:46:29 -05:00
|
|
|
|
|
|
|
|
|
if (map_op_type(map_op) == MAP_OP_INSERT) {
|
|
|
|
|
map = json_array_create_2(
|
|
|
|
|
ovsdb_atom_to_json(&map_op_datum(map_op)->keys[0],
|
|
|
|
|
key_type),
|
|
|
|
|
ovsdb_atom_to_json(&map_op_datum(map_op)->values[0],
|
|
|
|
|
value_type));
|
|
|
|
|
json_array_add(ins_map, map);
|
|
|
|
|
any_ins = true;
|
|
|
|
|
} else { /* MAP_OP_UPDATE or MAP_OP_DELETE */
|
|
|
|
|
map = ovsdb_atom_to_json(&map_op_datum(map_op)->keys[0],
|
|
|
|
|
key_type);
|
|
|
|
|
json_array_add(del_set, map);
|
|
|
|
|
any_del = true;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
}
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
/* Generate an additional insert mutate for updates. */
|
|
|
|
|
if (map_op_type(map_op) == MAP_OP_UPDATE) {
|
|
|
|
|
map = json_array_create_2(
|
|
|
|
|
ovsdb_atom_to_json(&map_op_datum(map_op)->keys[0],
|
|
|
|
|
key_type),
|
|
|
|
|
ovsdb_atom_to_json(&map_op_datum(map_op)->values[0],
|
|
|
|
|
value_type));
|
|
|
|
|
json_array_add(ins_map, map);
|
|
|
|
|
any_ins = true;
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
}
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
if (any_del) {
|
|
|
|
|
col_name = json_string_create(column->name);
|
|
|
|
|
mutator = json_string_create("delete");
|
|
|
|
|
map = json_array_create_2(json_string_create("set"), del_set);
|
|
|
|
|
mutation = json_array_create_3(col_name, mutator, map);
|
|
|
|
|
json_array_add(mutations, mutation);
|
|
|
|
|
any_mutations = true;
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(del_set);
|
|
|
|
|
}
|
|
|
|
|
if (any_ins) {
|
|
|
|
|
col_name = json_string_create(column->name);
|
|
|
|
|
mutator = json_string_create("insert");
|
|
|
|
|
map = json_array_create_2(json_string_create("map"), ins_map);
|
|
|
|
|
mutation = json_array_create_3(col_name, mutator, map);
|
|
|
|
|
json_array_add(mutations, mutation);
|
|
|
|
|
any_mutations = true;
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(ins_map);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
}
|
|
|
|
|
}
|
2016-08-06 17:46:29 -05:00
|
|
|
|
}
|
|
|
|
|
if (row->set_op_written) {
|
|
|
|
|
BITMAP_FOR_EACH_1(idx, class->n_columns, row->set_op_written) {
|
|
|
|
|
struct set_op_list *set_op_list;
|
|
|
|
|
const struct ovsdb_idl_column *column;
|
|
|
|
|
const struct ovsdb_datum *old_datum;
|
|
|
|
|
enum ovsdb_atomic_type key_type;
|
|
|
|
|
struct json *mutation, *set, *col_name, *mutator;
|
|
|
|
|
struct json *del_set, *ins_set;
|
|
|
|
|
bool any_del, any_ins;
|
|
|
|
|
|
|
|
|
|
set_op_list = row->set_op_lists[idx];
|
|
|
|
|
column = &class->columns[idx];
|
|
|
|
|
key_type = column->type.key.type;
|
|
|
|
|
|
|
|
|
|
/* Get the value to be changed */
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (row->new_datum && row->written
|
|
|
|
|
&& bitmap_is_set(row->written,idx)) {
|
|
|
|
|
old_datum = &row->new_datum[idx];
|
2017-08-11 11:06:47 -07:00
|
|
|
|
} else if (row->old_datum != NULL) {
|
|
|
|
|
old_datum = &row->old_datum[idx];
|
2016-08-06 17:46:29 -05:00
|
|
|
|
} else {
|
|
|
|
|
old_datum = ovsdb_datum_default(&column->type);
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
del_set = json_array_create_empty();
|
|
|
|
|
ins_set = json_array_create_empty();
|
|
|
|
|
any_del = false;
|
|
|
|
|
any_ins = false;
|
|
|
|
|
|
|
|
|
|
for (struct set_op *set_op = set_op_list_first(set_op_list); set_op;
|
|
|
|
|
set_op = set_op_list_next(set_op_list, set_op)) {
|
|
|
|
|
if (set_op_type(set_op) == SET_OP_INSERT) {
|
|
|
|
|
set = ovsdb_atom_to_json(&set_op_datum(set_op)->keys[0],
|
|
|
|
|
key_type);
|
|
|
|
|
json_array_add(ins_set, set);
|
|
|
|
|
any_ins = true;
|
|
|
|
|
} else { /* SETP_OP_DELETE */
|
|
|
|
|
/* Verify that there is a key to delete. */
|
ovsdb-data: Optimize union of sets.
Current algorithm of ovsdb_datum_union looks like this:
for-each atom in b:
if not bin_search(a, atom):
push(a, clone(atom))
quicksort(a)
So, the complexity looks like this:
Nb * log2(Na) + Nb + (Na + Nb) * log2(Na + Nb)
Comparisons clones Comparisons for quicksort
for search
ovsdb_datum_union() is heavily used in database transactions while
new element is added to a set. For example, if new logical switch
port is added to a logical switch in OVN. This is a very common
use case where CMS adds one new port to an existing switch that
already has, let's say, 100 ports. For this case ovsdb-server will
have to perform:
1 * log2(100) + 1 clone + 101 * log2(101)
Comparisons Comparisons for
for search quicksort.
~7 1 ~707
Roughly 714 comparisons of atoms and 1 clone.
Since binary search can give us position, where new atom should go
(it's the 'low' index after the search completion) for free, the
logic can be re-worked like this:
copied = 0
for-each atom in b:
desired_position = bin_search(a, atom)
push(result, a[ copied : desired_position - 1 ])
copied = desired_position
push(result, clone(atom))
push(result, a[ copied : Na ])
swap(a, result)
Complexity of this schema:
Nb * log2(Na) + Nb + Na
Comparisons clones memory copy on push
for search
'swap' is just a swap of a few pointers. 'push' is not a 'clone',
but a simple memory copy of 'union ovsdb_atom'.
In general, this schema substitutes complexity of a quicksort
with complexity of a memory copy of Na atom structures, where we're
not even copying strings that these atoms are pointing to.
Complexity in the example above goes down from 714 comparisons
to 7 comparisons and memcpy of 100 * sizeof (union ovsdb_atom) bytes.
General complexity of a memory copy should always be lower than
complexity of a quicksort, especially because these copies usually
performed in bulk, so this new schema should work faster for any input.
All in all, this change allows to execute several times more
transactions per second for transactions that adds new entries to sets.
Alternatively, union can be implemented as a linear merge of two
sorted arrays, but this will result in O(Na) comparisons, which
is more than Nb * log2(Na) in common case, since Na is usually
far bigger than Nb. Linear merge will also mean per-atom memory
copies instead of copying in bulk.
'replace' functionality of ovsdb_datum_union() had no users, so it
just removed. But it can easily be added back if needed in the future.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Han Zhou <hzhou@ovn.org>
Acked-by: Mark D. Gray <mark.d.gray@redhat.com>
2021-09-23 01:47:22 +02:00
|
|
|
|
if (!ovsdb_datum_find_key(old_datum,
|
|
|
|
|
&set_op_datum(set_op)->keys[0],
|
|
|
|
|
key_type, NULL)) {
|
2016-08-06 17:46:29 -05:00
|
|
|
|
/* No key to delete. Move on to next update. */
|
|
|
|
|
VLOG_WARN("Trying to delete a key that doesn't "
|
|
|
|
|
"exist in the set.");
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
set = ovsdb_atom_to_json(&set_op_datum(set_op)->keys[0],
|
|
|
|
|
key_type);
|
|
|
|
|
json_array_add(del_set, set);
|
|
|
|
|
any_del = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (any_del) {
|
|
|
|
|
col_name = json_string_create(column->name);
|
|
|
|
|
mutator = json_string_create("delete");
|
|
|
|
|
set = json_array_create_2(json_string_create("set"), del_set);
|
|
|
|
|
mutation = json_array_create_3(col_name, mutator, set);
|
|
|
|
|
json_array_add(mutations, mutation);
|
|
|
|
|
any_mutations = true;
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(del_set);
|
|
|
|
|
}
|
|
|
|
|
if (any_ins) {
|
|
|
|
|
col_name = json_string_create(column->name);
|
|
|
|
|
mutator = json_string_create("insert");
|
|
|
|
|
set = json_array_create_2(json_string_create("set"), ins_set);
|
|
|
|
|
mutation = json_array_create_3(col_name, mutator, set);
|
|
|
|
|
json_array_add(mutations, mutation);
|
|
|
|
|
any_mutations = true;
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(ins_set);
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return any_mutations;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Attempts to commit 'txn'. Returns the status of the commit operation, one
|
|
|
|
|
* of the following TXN_* constants:
|
|
|
|
|
*
|
|
|
|
|
* TXN_INCOMPLETE:
|
|
|
|
|
*
|
|
|
|
|
* The transaction is in progress, but not yet complete. The caller
|
|
|
|
|
* should call again later, after calling ovsdb_idl_run() to let the IDL
|
|
|
|
|
* do OVSDB protocol processing.
|
|
|
|
|
*
|
|
|
|
|
* TXN_UNCHANGED:
|
|
|
|
|
*
|
|
|
|
|
* The transaction is complete. (It didn't actually change the database,
|
|
|
|
|
* so the IDL didn't send any request to the database server.)
|
|
|
|
|
*
|
|
|
|
|
* TXN_ABORTED:
|
|
|
|
|
*
|
|
|
|
|
* The caller previously called ovsdb_idl_txn_abort().
|
|
|
|
|
*
|
|
|
|
|
* TXN_SUCCESS:
|
|
|
|
|
*
|
|
|
|
|
* The transaction was successful. The update made by the transaction
|
|
|
|
|
* (and possibly other changes made by other database clients) should
|
|
|
|
|
* already be visible in the IDL.
|
|
|
|
|
*
|
|
|
|
|
* TXN_TRY_AGAIN:
|
|
|
|
|
*
|
|
|
|
|
* The transaction failed for some transient reason, e.g. because a
|
|
|
|
|
* "verify" operation reported an inconsistency or due to a network
|
|
|
|
|
* problem. The caller should wait for a change to the database, then
|
|
|
|
|
* compose a new transaction, and commit the new transaction.
|
|
|
|
|
*
|
|
|
|
|
* Use the return value of ovsdb_idl_get_seqno() to wait for a change in
|
|
|
|
|
* the database. It is important to use its return value *before* the
|
|
|
|
|
* initial call to ovsdb_idl_txn_commit() as the baseline for this
|
|
|
|
|
* purpose, because the change that one should wait for can happen after
|
|
|
|
|
* the initial call but before the call that returns TXN_TRY_AGAIN, and
|
|
|
|
|
* using some other baseline value in that situation could cause an
|
|
|
|
|
* indefinite wait if the database rarely changes.
|
|
|
|
|
*
|
|
|
|
|
* TXN_NOT_LOCKED:
|
|
|
|
|
*
|
|
|
|
|
* The transaction failed because the IDL has been configured to require
|
|
|
|
|
* a database lock (with ovsdb_idl_set_lock()) but didn't get it yet or
|
|
|
|
|
* has already lost it.
|
|
|
|
|
*
|
|
|
|
|
* Committing a transaction rolls back all of the changes that it made to the
|
|
|
|
|
* IDL's copy of the database. If the transaction commits successfully, then
|
|
|
|
|
* the database server will send an update and, thus, the IDL will be updated
|
|
|
|
|
* with the committed changes. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
enum ovsdb_idl_txn_status
|
|
|
|
|
ovsdb_idl_txn_commit(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovsdb_idl *idl = txn->idl;
|
|
|
|
|
if (txn != idl->txn) {
|
2014-05-29 23:44:37 -07:00
|
|
|
|
goto coverage_out;
|
2020-11-21 11:47:01 -08:00
|
|
|
|
} else if (!ovsdb_cs_may_send_transaction(idl->cs)) {
|
2018-11-13 09:20:50 -08:00
|
|
|
|
txn->status = TXN_TRY_AGAIN;
|
|
|
|
|
goto disassemble_out;
|
2020-11-21 11:47:01 -08:00
|
|
|
|
} else if (ovsdb_cs_get_lock(idl->cs) && !ovsdb_cs_has_lock(idl->cs)) {
|
2011-07-26 16:49:03 -07:00
|
|
|
|
txn->status = TXN_NOT_LOCKED;
|
2014-05-29 23:44:37 -07:00
|
|
|
|
goto disassemble_out;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct json *operations = json_array_create_1(
|
|
|
|
|
json_string_create(idl->class_->database));
|
2011-07-26 16:49:03 -07:00
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
/* Add prerequisites and declarations of new rows. */
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovsdb_idl_row *row;
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH (row, txn_node, &txn->txn_rows) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
/* XXX check that deleted rows exist even if no prereqs? */
|
|
|
|
|
if (row->prereqs) {
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
size_t n_columns = class->n_columns;
|
|
|
|
|
struct json *op, *columns, *row_json;
|
|
|
|
|
size_t idx;
|
|
|
|
|
|
|
|
|
|
op = json_object_create();
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
json_object_put_string(op, "op", "wait");
|
|
|
|
|
json_object_put_string(op, "table", class->name);
|
|
|
|
|
json_object_put(op, "timeout", json_integer_create(0));
|
|
|
|
|
json_object_put(op, "where", where_uuid_equals(&row->uuid));
|
|
|
|
|
json_object_put_string(op, "until", "==");
|
|
|
|
|
columns = json_array_create_empty();
|
|
|
|
|
json_object_put(op, "columns", columns);
|
|
|
|
|
row_json = json_object_create();
|
|
|
|
|
json_object_put(op, "rows", json_array_create_1(row_json));
|
|
|
|
|
|
|
|
|
|
BITMAP_FOR_EACH_1 (idx, n_columns, row->prereqs) {
|
|
|
|
|
const struct ovsdb_idl_column *column = &class->columns[idx];
|
|
|
|
|
json_array_add(columns, json_string_create(column->name));
|
|
|
|
|
json_object_put(row_json, column->name,
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovsdb_datum_to_json(&row->old_datum[idx],
|
2009-12-07 17:08:04 -08:00
|
|
|
|
&column->type));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add updates. */
|
2020-11-21 11:47:01 -08:00
|
|
|
|
bool any_updates = false;
|
2018-05-17 13:16:55 -04:00
|
|
|
|
|
|
|
|
|
/* For tables constrained to have only a single row (a fairly common OVSDB
|
|
|
|
|
* pattern for storing global data), identify whether we're inserting a
|
|
|
|
|
* row. If so, then verify that the table is empty before inserting the
|
|
|
|
|
* row. This gives us a clear verification-related failure if there was an
|
|
|
|
|
* insertion race with another client. */
|
2020-11-21 11:47:01 -08:00
|
|
|
|
for (size_t i = 0; i < idl->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &idl->tables[i];
|
2018-05-17 13:16:55 -04:00
|
|
|
|
if (table->class_->is_singleton) {
|
|
|
|
|
/* Count the number of rows in the table before and after our
|
|
|
|
|
* transaction commits. This is O(n) in the number of rows in the
|
|
|
|
|
* table, but that's OK since we know that the table should only
|
|
|
|
|
* have one row. */
|
|
|
|
|
size_t initial_rows = 0;
|
|
|
|
|
size_t final_rows = 0;
|
|
|
|
|
HMAP_FOR_EACH (row, hmap_node, &table->rows) {
|
|
|
|
|
initial_rows += row->old_datum != NULL;
|
|
|
|
|
final_rows += row->new_datum != NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (initial_rows == 0 && final_rows == 1) {
|
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
json_object_put_string(op, "op", "wait");
|
|
|
|
|
json_object_put_string(op, "table", table->class_->name);
|
|
|
|
|
json_object_put(op, "where", json_array_create_empty());
|
|
|
|
|
json_object_put(op, "timeout", json_integer_create(0));
|
|
|
|
|
json_object_put_string(op, "until", "==");
|
|
|
|
|
json_object_put(op, "rows", json_array_create_empty());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH (row, txn_node, &txn->txn_rows) {
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (!row->new_datum) {
|
2011-04-12 11:31:58 -07:00
|
|
|
|
if (class->is_root) {
|
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op", "delete");
|
|
|
|
|
json_object_put_string(op, "table", class->name);
|
|
|
|
|
json_object_put(op, "where", where_uuid_equals(&row->uuid));
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
any_updates = true;
|
|
|
|
|
} else {
|
|
|
|
|
/* Let ovsdb-server decide whether to really delete it. */
|
|
|
|
|
}
|
2017-08-11 11:06:47 -07:00
|
|
|
|
} else if (row->old_datum != row->new_datum) {
|
2009-12-11 10:46:59 -08:00
|
|
|
|
struct json *row_json;
|
|
|
|
|
size_t idx;
|
|
|
|
|
|
2017-09-12 12:57:46 -07:00
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op",
|
|
|
|
|
row->old_datum ? "update" : "insert");
|
2009-12-11 10:46:59 -08:00
|
|
|
|
json_object_put_string(op, "table", class->name);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (row->old_datum) {
|
2009-12-11 10:46:59 -08:00
|
|
|
|
json_object_put(op, "where", where_uuid_equals(&row->uuid));
|
|
|
|
|
} else {
|
2010-01-28 13:23:30 -08:00
|
|
|
|
struct ovsdb_idl_txn_insert *insert;
|
|
|
|
|
|
2011-06-14 15:00:50 -07:00
|
|
|
|
any_updates = true;
|
|
|
|
|
|
2009-12-11 10:46:59 -08:00
|
|
|
|
json_object_put(op, "uuid-name",
|
|
|
|
|
json_string_create_nocopy(
|
2017-12-21 16:41:30 -08:00
|
|
|
|
ovsdb_data_row_name(&row->uuid)));
|
2010-01-28 13:23:30 -08:00
|
|
|
|
|
|
|
|
|
insert = xmalloc(sizeof *insert);
|
|
|
|
|
insert->dummy = row->uuid;
|
2018-05-24 10:32:59 -07:00
|
|
|
|
insert->op_index = operations->array.n - 1;
|
2010-01-28 13:23:30 -08:00
|
|
|
|
uuid_zero(&insert->real);
|
|
|
|
|
hmap_insert(&txn->inserted_rows, &insert->hmap_node,
|
|
|
|
|
uuid_hash(&insert->dummy));
|
2009-12-11 10:46:59 -08:00
|
|
|
|
}
|
|
|
|
|
row_json = json_object_create();
|
|
|
|
|
json_object_put(op, "row", row_json);
|
|
|
|
|
|
2010-06-24 15:31:18 -07:00
|
|
|
|
if (row->written) {
|
|
|
|
|
BITMAP_FOR_EACH_1 (idx, class->n_columns, row->written) {
|
|
|
|
|
const struct ovsdb_idl_column *column =
|
|
|
|
|
&class->columns[idx];
|
|
|
|
|
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (row->old_datum
|
2017-08-11 11:06:46 -07:00
|
|
|
|
|| !ovsdb_datum_is_default(&row->new_datum[idx],
|
2010-06-24 15:31:18 -07:00
|
|
|
|
&column->type)) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
struct json *value;
|
|
|
|
|
|
|
|
|
|
value = ovsdb_datum_to_json(&row->new_datum[idx],
|
|
|
|
|
&column->type);
|
2010-06-24 15:31:18 -07:00
|
|
|
|
json_object_put(row_json, column->name,
|
2017-08-11 11:06:46 -07:00
|
|
|
|
substitute_uuids(value, txn));
|
2011-06-14 15:00:50 -07:00
|
|
|
|
|
|
|
|
|
/* If anything really changed, consider it an update.
|
|
|
|
|
* We can't suppress not-really-changed values earlier
|
|
|
|
|
* or transactions would become nonatomic (see the big
|
|
|
|
|
* comment inside ovsdb_idl_txn_write()). */
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (!any_updates && row->old_datum &&
|
|
|
|
|
!ovsdb_datum_equals(&row->old_datum[idx],
|
2017-08-11 11:06:46 -07:00
|
|
|
|
&row->new_datum[idx],
|
2011-06-14 15:00:50 -07:00
|
|
|
|
&column->type)) {
|
|
|
|
|
any_updates = true;
|
|
|
|
|
}
|
2010-06-24 15:31:18 -07:00
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
2009-12-11 10:46:59 -08:00
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (!row->old_datum || !shash_is_empty(json_object(row_json))) {
|
2009-12-11 10:46:59 -08:00
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(op);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
/* Add mutate operation, for partial map or partial set updates. */
|
|
|
|
|
if (row->map_op_written || row->set_op_written) {
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
struct json *op, *mutations;
|
|
|
|
|
bool any_mutations;
|
|
|
|
|
|
|
|
|
|
op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op", "mutate");
|
|
|
|
|
json_object_put_string(op, "table", class->name);
|
|
|
|
|
json_object_put(op, "where", where_uuid_equals(&row->uuid));
|
|
|
|
|
mutations = json_array_create_empty();
|
|
|
|
|
any_mutations = ovsdb_idl_txn_extract_mutations(row, mutations);
|
|
|
|
|
json_object_put(op, "mutations", mutations);
|
|
|
|
|
|
|
|
|
|
if (any_mutations) {
|
|
|
|
|
op = substitute_uuids(op, txn);
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
any_updates = true;
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(op);
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
|
2009-12-16 16:26:17 -08:00
|
|
|
|
/* Add increment. */
|
2016-08-07 20:44:51 -07:00
|
|
|
|
if (txn->inc_table && (any_updates || txn->inc_force)) {
|
|
|
|
|
any_updates = true;
|
2018-05-24 10:32:59 -07:00
|
|
|
|
txn->inc_index = operations->array.n - 1;
|
2009-12-16 16:26:17 -08:00
|
|
|
|
|
2016-08-07 20:44:51 -07:00
|
|
|
|
struct json *op = json_object_create();
|
2009-12-16 16:26:17 -08:00
|
|
|
|
json_object_put_string(op, "op", "mutate");
|
|
|
|
|
json_object_put_string(op, "table", txn->inc_table);
|
|
|
|
|
json_object_put(op, "where",
|
2012-04-12 08:25:10 -07:00
|
|
|
|
substitute_uuids(where_uuid_equals(&txn->inc_row),
|
|
|
|
|
txn));
|
2009-12-16 16:26:17 -08:00
|
|
|
|
json_object_put(op, "mutations",
|
|
|
|
|
json_array_create_1(
|
|
|
|
|
json_array_create_3(
|
|
|
|
|
json_string_create(txn->inc_column),
|
|
|
|
|
json_string_create("+="),
|
|
|
|
|
json_integer_create(1))));
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
|
|
|
|
|
op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op", "select");
|
|
|
|
|
json_object_put_string(op, "table", txn->inc_table);
|
|
|
|
|
json_object_put(op, "where",
|
2012-04-12 08:25:10 -07:00
|
|
|
|
substitute_uuids(where_uuid_equals(&txn->inc_row),
|
|
|
|
|
txn));
|
2009-12-16 16:26:17 -08:00
|
|
|
|
json_object_put(op, "columns",
|
|
|
|
|
json_array_create_1(json_string_create(
|
|
|
|
|
txn->inc_column)));
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-16 13:30:53 -08:00
|
|
|
|
if (txn->comment.length) {
|
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op", "comment");
|
|
|
|
|
json_object_put_string(op, "comment", ds_cstr(&txn->comment));
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-11 11:28:36 -08:00
|
|
|
|
if (txn->dry_run) {
|
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op", "abort");
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-08 17:14:36 -08:00
|
|
|
|
if (!any_updates) {
|
2009-12-16 16:26:17 -08:00
|
|
|
|
txn->status = TXN_UNCHANGED;
|
2010-01-12 10:51:52 -08:00
|
|
|
|
json_destroy(operations);
|
2009-12-08 17:14:36 -08:00
|
|
|
|
} else {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
txn->request_id = ovsdb_cs_send_transaction(idl->cs, operations);
|
|
|
|
|
if (txn->request_id) {
|
|
|
|
|
hmap_insert(&idl->outstanding_txns, &txn->hmap_node,
|
|
|
|
|
json_hash(txn->request_id, 0));
|
|
|
|
|
txn->status = TXN_INCOMPLETE;
|
|
|
|
|
} else {
|
|
|
|
|
txn->status = TXN_TRY_AGAIN;
|
|
|
|
|
}
|
2009-12-08 17:14:36 -08:00
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2014-05-29 23:44:37 -07:00
|
|
|
|
disassemble_out:
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_txn_disassemble(txn);
|
2014-05-29 23:44:37 -07:00
|
|
|
|
coverage_out:
|
|
|
|
|
switch (txn->status) {
|
|
|
|
|
case TXN_UNCOMMITTED: COVERAGE_INC(txn_uncommitted); break;
|
|
|
|
|
case TXN_UNCHANGED: COVERAGE_INC(txn_unchanged); break;
|
|
|
|
|
case TXN_INCOMPLETE: COVERAGE_INC(txn_incomplete); break;
|
|
|
|
|
case TXN_ABORTED: COVERAGE_INC(txn_aborted); break;
|
|
|
|
|
case TXN_SUCCESS: COVERAGE_INC(txn_success); break;
|
|
|
|
|
case TXN_TRY_AGAIN: COVERAGE_INC(txn_try_again); break;
|
|
|
|
|
case TXN_NOT_LOCKED: COVERAGE_INC(txn_not_locked); break;
|
|
|
|
|
case TXN_ERROR: COVERAGE_INC(txn_error); break;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
return txn->status;
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-03 12:55:39 -08:00
|
|
|
|
/* Attempts to commit 'txn', blocking until the commit either succeeds or
|
|
|
|
|
* fails. Returns the final commit status, which may be any TXN_* value other
|
2012-04-12 08:27:56 -07:00
|
|
|
|
* than TXN_INCOMPLETE.
|
|
|
|
|
*
|
|
|
|
|
* This function calls ovsdb_idl_run() on 'txn''s IDL, so it may cause the
|
|
|
|
|
* return value of ovsdb_idl_get_seqno() to change. */
|
2010-03-03 12:55:39 -08:00
|
|
|
|
enum ovsdb_idl_txn_status
|
|
|
|
|
ovsdb_idl_txn_commit_block(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
enum ovsdb_idl_txn_status status;
|
|
|
|
|
|
2010-04-13 09:28:13 -07:00
|
|
|
|
fatal_signal_run();
|
2010-03-03 12:55:39 -08:00
|
|
|
|
while ((status = ovsdb_idl_txn_commit(txn)) == TXN_INCOMPLETE) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_run(txn->idl);
|
|
|
|
|
ovsdb_idl_wait(txn->idl);
|
2010-03-03 12:55:39 -08:00
|
|
|
|
ovsdb_idl_txn_wait(txn);
|
|
|
|
|
poll_block();
|
|
|
|
|
}
|
|
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns the final (incremented) value of the column in 'txn' that was set to
|
|
|
|
|
* be incremented by ovsdb_idl_txn_increment(). 'txn' must have committed
|
|
|
|
|
* successfully. */
|
2009-12-16 16:26:17 -08:00
|
|
|
|
int64_t
|
|
|
|
|
ovsdb_idl_txn_get_increment_new_value(const struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(txn->status == TXN_SUCCESS);
|
2009-12-16 16:26:17 -08:00
|
|
|
|
return txn->inc_new_value;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Aborts 'txn' without sending it to the database server. This is effective
|
|
|
|
|
* only if ovsdb_idl_txn_commit() has not yet been called for 'txn'.
|
|
|
|
|
* Otherwise, it has no effect.
|
|
|
|
|
*
|
|
|
|
|
* Aborting a transaction doesn't free its memory. Use
|
|
|
|
|
* ovsdb_idl_txn_destroy() to do that. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_abort(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
ovsdb_idl_txn_disassemble(txn);
|
2011-06-20 16:17:44 -07:00
|
|
|
|
if (txn->status == TXN_UNCOMMITTED || txn->status == TXN_INCOMPLETE) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
txn->status = TXN_ABORTED;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns a string that reports the error status for 'txn'. The caller must
|
|
|
|
|
* not modify or free the returned string. A call to ovsdb_idl_txn_destroy()
|
|
|
|
|
* for 'txn' may free the returned string.
|
|
|
|
|
*
|
|
|
|
|
* The return value is ordinarily one of the strings that
|
|
|
|
|
* ovsdb_idl_txn_status_to_string() would return, but if the transaction failed
|
|
|
|
|
* due to an error reported by the database server, the return value is that
|
|
|
|
|
* error. */
|
2010-02-05 14:11:12 -08:00
|
|
|
|
const char *
|
|
|
|
|
ovsdb_idl_txn_get_error(const struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
if (txn->status != TXN_ERROR) {
|
|
|
|
|
return ovsdb_idl_txn_status_to_string(txn->status);
|
|
|
|
|
} else if (txn->error) {
|
|
|
|
|
return txn->error;
|
|
|
|
|
} else {
|
|
|
|
|
return "no error details available";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_set_error_json(struct ovsdb_idl_txn *txn,
|
|
|
|
|
const struct json *json)
|
|
|
|
|
{
|
2017-12-31 21:15:58 -08:00
|
|
|
|
if (json && txn->error == NULL) {
|
2010-02-05 14:11:12 -08:00
|
|
|
|
txn->error = json_to_string(json, JSSF_SORT);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
/* For transaction 'txn' that completed successfully, finds and returns the
|
|
|
|
|
* permanent UUID that the database assigned to a newly inserted row, given the
|
|
|
|
|
* 'uuid' that ovsdb_idl_txn_insert() assigned locally to that row.
|
|
|
|
|
*
|
|
|
|
|
* Returns NULL if 'uuid' is not a UUID assigned by ovsdb_idl_txn_insert() or
|
|
|
|
|
* if it was assigned by that function and then deleted by
|
|
|
|
|
* ovsdb_idl_txn_delete() within the same transaction. (Rows that are inserted
|
|
|
|
|
* and then deleted within a single transaction are never sent to the database
|
|
|
|
|
* server, so it never assigns them a permanent UUID.) */
|
|
|
|
|
const struct uuid *
|
|
|
|
|
ovsdb_idl_txn_get_insert_uuid(const struct ovsdb_idl_txn *txn,
|
|
|
|
|
const struct uuid *uuid)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_txn_insert *insert;
|
|
|
|
|
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(txn->status == TXN_SUCCESS || txn->status == TXN_UNCHANGED);
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_IN_BUCKET (insert, hmap_node,
|
2010-01-28 13:23:30 -08:00
|
|
|
|
uuid_hash(uuid), &txn->inserted_rows) {
|
|
|
|
|
if (uuid_equals(uuid, &insert->dummy)) {
|
|
|
|
|
return &insert->real;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_complete(struct ovsdb_idl_txn *txn,
|
|
|
|
|
enum ovsdb_idl_txn_status status)
|
|
|
|
|
{
|
|
|
|
|
txn->status = status;
|
2020-11-21 11:47:01 -08:00
|
|
|
|
hmap_remove(&txn->idl->outstanding_txns, &txn->hmap_node);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
|
2013-03-05 15:30:33 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_write__(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum, bool owns_datum)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
2012-07-13 16:00:29 -07:00
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
2011-10-26 15:46:48 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
2012-09-20 11:13:15 -07:00
|
|
|
|
bool write_only;
|
2011-10-26 15:46:48 -07:00
|
|
|
|
|
2016-10-07 09:47:43 -07:00
|
|
|
|
ovs_assert(!column->is_synthetic);
|
2011-10-26 15:46:48 -07:00
|
|
|
|
if (ovsdb_idl_row_is_synthetic(row)) {
|
2013-03-05 15:30:33 -08:00
|
|
|
|
goto discard_datum;
|
2011-10-26 15:46:48 -07:00
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
2011-10-26 15:46:48 -07:00
|
|
|
|
column_idx = column - class->columns;
|
2012-09-20 11:13:15 -07:00
|
|
|
|
write_only = row->table->modes[column_idx] == OVSDB_IDL_MONITOR;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovs_assert(row->new_datum != NULL);
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(column_idx < class->n_columns);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovs_assert(row->old_datum == NULL ||
|
2012-11-06 13:14:55 -08:00
|
|
|
|
row->table->modes[column_idx] & OVSDB_IDL_MONITOR);
|
2010-08-11 15:41:41 -07:00
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
if (row->table->idl->verify_write_only && !write_only) {
|
2012-09-20 11:13:15 -07:00
|
|
|
|
VLOG_ERR("Bug: Attempt to write to a read/write column (%s:%s) when"
|
|
|
|
|
" explicitly configured not to.", class->name, column->name);
|
2013-03-05 15:30:33 -08:00
|
|
|
|
goto discard_datum;
|
2012-09-20 11:13:15 -07:00
|
|
|
|
}
|
|
|
|
|
|
2011-04-01 10:50:52 -07:00
|
|
|
|
/* If this is a write-only column and the datum being written is the same
|
|
|
|
|
* as the one already there, just skip the update entirely. This is worth
|
|
|
|
|
* optimizing because we have a lot of columns that get periodically
|
|
|
|
|
* refreshed into the database but don't actually change that often.
|
|
|
|
|
*
|
|
|
|
|
* We don't do this for read/write columns because that would break
|
|
|
|
|
* atomicity of transactions--some other client might have written a
|
2011-06-14 15:00:50 -07:00
|
|
|
|
* different value in that column since we read it. (But if a whole
|
|
|
|
|
* transaction only does writes of existing values, without making any real
|
|
|
|
|
* changes, we will drop the whole transaction later in
|
|
|
|
|
* ovsdb_idl_txn_commit().) */
|
2020-08-10 23:15:10 -07:00
|
|
|
|
if (write_only && ovsdb_datum_equals(ovsdb_idl_read(row, column),
|
2012-09-20 11:13:15 -07:00
|
|
|
|
datum, &column->type)) {
|
2013-03-05 15:30:33 -08:00
|
|
|
|
goto discard_datum;
|
2011-04-01 10:50:52 -07:00
|
|
|
|
}
|
|
|
|
|
|
2018-08-14 11:31:46 -07:00
|
|
|
|
bool index_row = is_index_row(row);
|
|
|
|
|
if (!index_row) {
|
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (hmap_node_is_null(&row->txn_node)) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
hmap_insert(&row->table->idl->txn->txn_rows, &row->txn_node,
|
2009-12-07 17:08:04 -08:00
|
|
|
|
uuid_hash(&row->uuid));
|
|
|
|
|
}
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (row->old_datum == row->new_datum) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum = xmalloc(class->n_columns * sizeof *row->new_datum);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
if (!row->written) {
|
|
|
|
|
row->written = bitmap_allocate(class->n_columns);
|
|
|
|
|
}
|
|
|
|
|
if (bitmap_is_set(row->written, column_idx)) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovsdb_datum_destroy(&row->new_datum[column_idx], &column->type);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
} else {
|
|
|
|
|
bitmap_set1(row->written, column_idx);
|
|
|
|
|
}
|
2013-03-05 15:30:33 -08:00
|
|
|
|
if (owns_datum) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum[column_idx] = *datum;
|
2013-03-05 15:30:33 -08:00
|
|
|
|
} else {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovsdb_datum_clone(&row->new_datum[column_idx], datum, &column->type);
|
2013-03-05 15:30:33 -08:00
|
|
|
|
}
|
2010-01-25 10:15:17 -08:00
|
|
|
|
(column->unparse)(row);
|
2017-08-11 11:06:46 -07:00
|
|
|
|
(column->parse)(row, &row->new_datum[column_idx]);
|
ovsdb-idl: Mark row "parsed" in ovsdb_idl_txn_write__
Once a column is set in a row using ovsdb_idl_txn_write__ we also mark
the row "parsed". Otherwise the memory allocated by
sbrec_<table>_parse_<col>() will never be freed. After marking the row
"parsed", the ovsdb_idl_txn_disassemble function will properly free the
newly allocated memory for the column (ovsdb_idl_row_unparse).
The problem is present only for rows that are inserted by the
running application because rows that are loaded from the database
will always have row->parsed == true.
One way to detect the leak is to start northd with valgrind:
valgrind --tool=memcheck --leak-check=yes ./ovn-northd
Then create a logical switch and bind a logical port to it:
ovn-nbctl ls-add ls1
ovn-nbctl lsp-add ls1 ls1-vm1
The valgrind report:
==9270== Memcheck, a memory error detector
==9270== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9270== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright
info
==9270== Command: ./ovn-northd
==9270==
<snip>
==9270==
==9270== 8 bytes in 1 blocks are definitely lost in loss record 30 of
292
==9270== at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==9270== by 0x4D31EF: xmalloc (util.c:138)
==9270== by 0x45CB8E: sbrec_multicast_group_parse_ports (ovn-sb-idl.c:18141)
==9270== by 0x4BB12D: ovsdb_idl_txn_write__ (ovsdb-idl.c:4489)
==9270== by 0x4BB1B5: ovsdb_idl_txn_write (ovsdb-idl.c:4527)
==9270== by 0x45D167: sbrec_multicast_group_set_ports (ovn-sb-idl.c:18561)
==9270== by 0x40F416: ovn_multicast_update_sbrec (ovn-northd.c:2947)
==9270== by 0x41FC55: build_lflows (ovn-northd.c:7981)
==9270== by 0x421830: ovnnb_db_run (ovn-northd.c:8522)
==9270== by 0x422B2D: ovn_db_run (ovn-northd.c:9089)
==9270== by 0x423909: main (ovn-northd.c:9409)
==9270==
==9270== 157 (32 direct, 125 indirect) bytes in 1 blocks are definitely
lost in loss record 199 of 292
==9270== at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==9270== by 0x4D31EF: xmalloc (util.c:138)
==9270== by 0x471E3D: resize (hmap.c:100)
==9270== by 0x4720C8: hmap_expand_at (hmap.c:175)
==9270== by 0x4C74F1: hmap_insert_at (hmap.h:277)
==9270== by 0x4C825A: smap_add__ (smap.c:392)
==9270== by 0x4C7783: smap_add (smap.c:55)
==9270== by 0x451054: sbrec_datapath_binding_parse_external_ids (ovn-sb-idl.c:7181)
==9270== by 0x4BB12D: ovsdb_idl_txn_write__ (ovsdb-idl.c:4489)
==9270== by 0x4BB1B5: ovsdb_idl_txn_write (ovsdb-idl.c:4527)
==9270== by 0x451436: sbrec_datapath_binding_set_external_ids (ovn-sb-idl.c:7444)
==9270== by 0x4090F1: ovn_datapath_update_external_ids (ovn-northd.c:817)
==9270==
<snip>
==9270==
==9270== LEAK SUMMARY:
==9270== definitely lost: 1,322 bytes in 47 blocks
==9270== indirectly lost: 4,653 bytes in 240 blocks
==9270== possibly lost: 0 bytes in 0 blocks
==9270== still reachable: 254,004 bytes in 7,780 blocks
==9270== suppressed: 0 bytes in 0 blocks
==9270== Reachable blocks (those to which a pointer was found) are not
shown.
==9270== To see them, rerun with: --leak-check=full
--show-leak-kinds=all
==9270==
==9270== For counts of detected and suppressed errors, rerun with: -v
==9270== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 0 from 0)
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-07-17 21:05:04 +02:00
|
|
|
|
row->parsed = true;
|
2018-08-14 11:31:46 -07:00
|
|
|
|
if (!index_row) {
|
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
|
|
|
|
}
|
2013-03-05 15:30:33 -08:00
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
discard_datum:
|
|
|
|
|
if (owns_datum) {
|
|
|
|
|
ovsdb_datum_destroy(datum, &column->type);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-31 11:34:53 -07:00
|
|
|
|
/* Writes 'datum' to the specified 'column' in 'row_'. Updates both 'row_'
|
|
|
|
|
* itself and the structs derived from it (e.g. the "struct ovsrec_*", for
|
|
|
|
|
* ovs-vswitchd).
|
|
|
|
|
*
|
2016-08-31 11:42:53 -07:00
|
|
|
|
* 'datum' must have the correct type for its column, but it needs not be
|
|
|
|
|
* sorted or unique because this function will take care of that. The IDL does
|
|
|
|
|
* not check that it meets schema constraints, but ovsdb-server will do so at
|
|
|
|
|
* commit time so it had better be correct.
|
2016-08-31 11:34:53 -07:00
|
|
|
|
*
|
|
|
|
|
* A transaction must be in progress. Replication of 'column' must not have
|
|
|
|
|
* been disabled (by calling ovsdb_idl_omit()).
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "set" functions
|
|
|
|
|
* generated by ovsdb-idlc.
|
|
|
|
|
*
|
|
|
|
|
* Takes ownership of what 'datum' points to (and in some cases destroys that
|
|
|
|
|
* data before returning) but makes a copy of 'datum' itself. (Commonly
|
|
|
|
|
* 'datum' is on the caller's stack.) */
|
2013-03-05 15:30:33 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_write(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
2016-08-31 11:42:53 -07:00
|
|
|
|
ovsdb_datum_sort_unique(datum,
|
|
|
|
|
column->type.key.type, column->type.value.type);
|
2013-03-05 15:30:33 -08:00
|
|
|
|
ovsdb_idl_txn_write__(row, column, datum, true);
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-31 11:42:53 -07:00
|
|
|
|
/* Similar to ovsdb_idl_txn_write(), except:
|
|
|
|
|
*
|
|
|
|
|
* - The caller retains ownership of 'datum' and what it points to.
|
|
|
|
|
*
|
|
|
|
|
* - The caller must ensure that 'datum' is sorted and unique (e.g. via
|
|
|
|
|
* ovsdb_datum_sort_unique().) */
|
2013-03-05 15:30:33 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_write_clone(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
const struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
ovsdb_idl_txn_write__(row, column,
|
|
|
|
|
CONST_CAST(struct ovsdb_datum *, datum), false);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-10-25 10:43:28 -07:00
|
|
|
|
/* Causes the original contents of 'column' in 'row_' to be verified as a
|
|
|
|
|
* prerequisite to completing the transaction. That is, if 'column' in 'row_'
|
|
|
|
|
* changed (or if 'row_' was deleted) between the time that the IDL originally
|
|
|
|
|
* read its contents and the time that the transaction commits, then the
|
2016-09-19 16:23:20 -07:00
|
|
|
|
* transaction aborts and ovsdb_idl_txn_commit() returns TXN_TRY_AGAIN.
|
2010-10-25 10:43:28 -07:00
|
|
|
|
*
|
|
|
|
|
* The intention is that, to ensure that no transaction commits based on dirty
|
|
|
|
|
* reads, an application should call ovsdb_idl_txn_verify() on each data item
|
|
|
|
|
* read as part of a read-modify-write operation.
|
|
|
|
|
*
|
|
|
|
|
* In some cases ovsdb_idl_txn_verify() reduces to a no-op, because the current
|
|
|
|
|
* value of 'column' is already known:
|
|
|
|
|
*
|
|
|
|
|
* - If 'row_' is a row created by the current transaction (returned by
|
|
|
|
|
* ovsdb_idl_txn_insert()).
|
|
|
|
|
*
|
|
|
|
|
* - If 'column' has already been modified (with ovsdb_idl_txn_write())
|
|
|
|
|
* within the current transaction.
|
|
|
|
|
*
|
|
|
|
|
* Because of the latter property, always call ovsdb_idl_txn_verify() *before*
|
|
|
|
|
* ovsdb_idl_txn_write() for a given read-modify-write.
|
|
|
|
|
*
|
|
|
|
|
* A transaction must be in progress.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "verify"
|
|
|
|
|
* functions generated by ovsdb-idlc. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_verify(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2012-07-13 16:00:29 -07:00
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
2011-10-26 15:46:48 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
|
|
|
|
|
|
|
|
|
if (ovsdb_idl_row_is_synthetic(row)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
2011-10-26 15:46:48 -07:00
|
|
|
|
column_idx = column - class->columns;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovs_assert(row->new_datum != NULL);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovs_assert(row->old_datum == NULL ||
|
2012-11-06 13:14:55 -08:00
|
|
|
|
row->table->modes[column_idx] & OVSDB_IDL_MONITOR);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (!row->old_datum
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|| (row->written && bitmap_is_set(row->written, column_idx))) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (hmap_node_is_null(&row->txn_node)) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
hmap_insert(&row->table->idl->txn->txn_rows, &row->txn_node,
|
2009-12-07 17:08:04 -08:00
|
|
|
|
uuid_hash(&row->uuid));
|
|
|
|
|
}
|
|
|
|
|
if (!row->prereqs) {
|
|
|
|
|
row->prereqs = bitmap_allocate(class->n_columns);
|
|
|
|
|
}
|
|
|
|
|
bitmap_set1(row->prereqs, column_idx);
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-25 10:43:28 -07:00
|
|
|
|
/* Deletes 'row_' from its table. May free 'row_', so it must not be
|
|
|
|
|
* accessed afterward.
|
|
|
|
|
*
|
|
|
|
|
* A transaction must be in progress.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "delete"
|
|
|
|
|
* functions generated by ovsdb-idlc. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
void
|
2010-01-27 13:04:56 -08:00
|
|
|
|
ovsdb_idl_txn_delete(const struct ovsdb_idl_row *row_)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
2012-07-13 16:00:29 -07:00
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
2010-01-27 13:04:56 -08:00
|
|
|
|
|
2011-10-26 15:46:48 -07:00
|
|
|
|
if (ovsdb_idl_row_is_synthetic(row)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovs_assert(row->new_datum != NULL);
|
2018-08-14 11:31:46 -07:00
|
|
|
|
ovs_assert(!is_index_row(row_));
|
|
|
|
|
ovsdb_idl_remove_from_indexes(row_);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (!row->old_datum) {
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_row_clear_new(row);
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(!row->prereqs);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
hmap_remove(&row->table->rows, &row->hmap_node);
|
2020-11-21 11:47:01 -08:00
|
|
|
|
hmap_remove(&row->table->idl->txn->txn_rows, &row->txn_node);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
free(row);
|
2010-01-21 10:51:37 -08:00
|
|
|
|
return;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
if (hmap_node_is_null(&row->txn_node)) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
hmap_insert(&row->table->idl->txn->txn_rows, &row->txn_node,
|
2009-12-07 17:08:04 -08:00
|
|
|
|
uuid_hash(&row->uuid));
|
|
|
|
|
}
|
2009-12-11 13:16:15 -08:00
|
|
|
|
ovsdb_idl_row_clear_new(row);
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum = NULL;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-10-25 10:43:28 -07:00
|
|
|
|
/* Inserts and returns a new row in the table with the specified 'class' in the
|
|
|
|
|
* database with open transaction 'txn'.
|
|
|
|
|
*
|
|
|
|
|
* The new row is assigned a provisional UUID. If 'uuid' is null then one is
|
|
|
|
|
* randomly generated; otherwise 'uuid' should specify a randomly generated
|
|
|
|
|
* UUID not otherwise in use. ovsdb-server will assign a different UUID when
|
|
|
|
|
* 'txn' is committed, but the IDL will replace any uses of the provisional
|
|
|
|
|
* UUID in the data to be to be committed by the UUID assigned by
|
|
|
|
|
* ovsdb-server.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "insert"
|
|
|
|
|
* functions generated by ovsdb-idlc. */
|
2010-01-27 13:04:56 -08:00
|
|
|
|
const struct ovsdb_idl_row *
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_txn_insert(struct ovsdb_idl_txn *txn,
|
2010-06-02 11:08:03 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class,
|
|
|
|
|
const struct uuid *uuid)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = ovsdb_idl_row_create__(class);
|
2010-06-02 11:08:03 -07:00
|
|
|
|
|
|
|
|
|
if (uuid) {
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(!ovsdb_idl_txn_get_row(txn, uuid));
|
2010-06-02 11:08:03 -07:00
|
|
|
|
row->uuid = *uuid;
|
|
|
|
|
} else {
|
|
|
|
|
uuid_generate(&row->uuid);
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
row->table = ovsdb_idl_table_from_class(txn->idl, class);
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum = xmalloc(class->n_columns * sizeof *row->new_datum);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
hmap_insert(&row->table->rows, &row->hmap_node, uuid_hash(&row->uuid));
|
2009-12-07 17:08:04 -08:00
|
|
|
|
hmap_insert(&txn->txn_rows, &row->txn_node, uuid_hash(&row->uuid));
|
2018-08-14 11:31:46 -07:00
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
2020-10-20 11:07:07 -04:00
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_txn_abort_all(struct ovsdb_idl *idl)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_txn *txn;
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
HMAP_FOR_EACH (txn, hmap_node, &idl->outstanding_txns) {
|
2012-03-27 10:16:52 -07:00
|
|
|
|
ovsdb_idl_txn_complete(txn, TXN_TRY_AGAIN);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct ovsdb_idl_txn *
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_idl_txn_find(struct ovsdb_idl *idl, const struct json *id)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_txn *txn;
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_WITH_HASH (txn, hmap_node,
|
2020-11-21 11:47:01 -08:00
|
|
|
|
json_hash(id, 0), &idl->outstanding_txns) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (json_equal(id, txn->request_id)) {
|
|
|
|
|
return txn;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-16 16:26:17 -08:00
|
|
|
|
static bool
|
|
|
|
|
check_json_type(const struct json *json, enum json_type type, const char *name)
|
|
|
|
|
{
|
|
|
|
|
if (!json) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "%s is missing", name);
|
|
|
|
|
return false;
|
|
|
|
|
} else if (json->type != type) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "%s is %s instead of %s",
|
|
|
|
|
name, json_type_to_string(json->type),
|
|
|
|
|
json_type_to_string(type));
|
|
|
|
|
return false;
|
|
|
|
|
} else {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_txn_process_inc_reply(struct ovsdb_idl_txn *txn,
|
|
|
|
|
const struct json_array *results)
|
|
|
|
|
{
|
|
|
|
|
struct json *count, *rows, *row, *column;
|
|
|
|
|
struct shash *mutate, *select;
|
|
|
|
|
|
|
|
|
|
if (txn->inc_index + 2 > results->n) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "reply does not contain enough operations "
|
2013-11-25 23:38:48 -08:00
|
|
|
|
"for increment (has %"PRIuSIZE", needs %u)",
|
2009-12-16 16:26:17 -08:00
|
|
|
|
results->n, txn->inc_index + 2);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
/* We know that this is a JSON object because the loop in
|
2020-11-21 11:47:01 -08:00
|
|
|
|
* ovsdb_idl_txn_process_reply() checked. */
|
2009-12-16 16:26:17 -08:00
|
|
|
|
mutate = json_object(results->elems[txn->inc_index]);
|
|
|
|
|
count = shash_find_data(mutate, "count");
|
|
|
|
|
if (!check_json_type(count, JSON_INTEGER, "\"mutate\" reply \"count\"")) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (count->integer != 1) {
|
2009-12-16 16:26:17 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl,
|
2010-05-17 15:08:17 +08:00
|
|
|
|
"\"mutate\" reply \"count\" is %lld instead of 1",
|
2018-05-24 10:32:59 -07:00
|
|
|
|
count->integer);
|
2009-12-16 16:26:17 -08:00
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
select = json_object(results->elems[txn->inc_index + 1]);
|
|
|
|
|
rows = shash_find_data(select, "rows");
|
|
|
|
|
if (!check_json_type(rows, JSON_ARRAY, "\"select\" reply \"rows\"")) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (rows->array.n != 1) {
|
2013-11-25 23:38:48 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "\"select\" reply \"rows\" has %"PRIuSIZE" elements "
|
2009-12-16 16:26:17 -08:00
|
|
|
|
"instead of 1",
|
2018-05-24 10:32:59 -07:00
|
|
|
|
rows->array.n);
|
2009-12-16 16:26:17 -08:00
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-05-24 10:32:59 -07:00
|
|
|
|
row = rows->array.elems[0];
|
2009-12-16 16:26:17 -08:00
|
|
|
|
if (!check_json_type(row, JSON_OBJECT, "\"select\" reply row")) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
column = shash_find_data(json_object(row), txn->inc_column);
|
|
|
|
|
if (!check_json_type(column, JSON_INTEGER,
|
|
|
|
|
"\"select\" reply inc column")) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-05-24 10:32:59 -07:00
|
|
|
|
txn->inc_new_value = column->integer;
|
2009-12-16 16:26:17 -08:00
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_txn_process_insert_reply(struct ovsdb_idl_txn_insert *insert,
|
|
|
|
|
const struct json_array *results)
|
|
|
|
|
{
|
2010-02-08 14:09:36 -08:00
|
|
|
|
static const struct ovsdb_base_type uuid_type = OVSDB_BASE_UUID_INIT;
|
2010-01-28 13:23:30 -08:00
|
|
|
|
struct ovsdb_error *error;
|
|
|
|
|
struct json *json_uuid;
|
|
|
|
|
union ovsdb_atom uuid;
|
|
|
|
|
struct shash *reply;
|
|
|
|
|
|
|
|
|
|
if (insert->op_index >= results->n) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "reply does not contain enough operations "
|
2013-11-25 23:38:48 -08:00
|
|
|
|
"for insert (has %"PRIuSIZE", needs %u)",
|
2010-01-28 13:23:30 -08:00
|
|
|
|
results->n, insert->op_index);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* We know that this is a JSON object because the loop in
|
|
|
|
|
* ovsdb_idl_txn_process_reply() checked. */
|
|
|
|
|
reply = json_object(results->elems[insert->op_index]);
|
|
|
|
|
json_uuid = shash_find_data(reply, "uuid");
|
|
|
|
|
if (!check_json_type(json_uuid, JSON_ARRAY, "\"insert\" reply \"uuid\"")) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2010-02-08 14:09:36 -08:00
|
|
|
|
error = ovsdb_atom_from_json(&uuid, &uuid_type, json_uuid, NULL);
|
2010-01-28 13:23:30 -08:00
|
|
|
|
if (error) {
|
2017-12-13 11:32:28 -08:00
|
|
|
|
char *s = ovsdb_error_to_string_free(error);
|
2010-01-28 13:23:30 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "\"insert\" reply \"uuid\" is not a JSON "
|
|
|
|
|
"UUID: %s", s);
|
|
|
|
|
free(s);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
insert->real = uuid.uuid;
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
2009-12-16 16:26:17 -08:00
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_process_reply(struct ovsdb_idl *idl,
|
|
|
|
|
const struct jsonrpc_msg *msg)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovsdb_idl_txn *txn = ovsdb_idl_txn_find(idl, msg->id);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (!txn) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
|
2020-11-21 11:47:01 -08:00
|
|
|
|
enum ovsdb_idl_txn_status status;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (msg->type == JSONRPC_ERROR) {
|
2017-12-31 21:15:58 -08:00
|
|
|
|
if (msg->error
|
|
|
|
|
&& msg->error->type == JSON_STRING
|
|
|
|
|
&& !strcmp(json_string(msg->error), "canceled")) {
|
|
|
|
|
/* ovsdb-server uses this error message to indicate that the
|
|
|
|
|
* transaction was canceled because the database in question was
|
|
|
|
|
* removed, converted, etc. */
|
|
|
|
|
status = TXN_TRY_AGAIN;
|
|
|
|
|
} else {
|
|
|
|
|
status = TXN_ERROR;
|
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, msg->error);
|
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
} else if (msg->result->type != JSON_ARRAY) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "reply to \"transact\" is not JSON array");
|
|
|
|
|
status = TXN_ERROR;
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, msg->result);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
} else {
|
2018-05-24 10:32:59 -07:00
|
|
|
|
struct json_array *ops = &msg->result->array;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
int hard_errors = 0;
|
|
|
|
|
int soft_errors = 0;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
int lock_errors = 0;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
size_t i;
|
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
for (i = 0; i < ops->n; i++) {
|
|
|
|
|
struct json *op = ops->elems[i];
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
if (op->type == JSON_NULL) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
/* This isn't an error in itself but indicates that some prior
|
|
|
|
|
* operation failed, so make sure that we know about it. */
|
|
|
|
|
soft_errors++;
|
2010-01-28 13:23:30 -08:00
|
|
|
|
} else if (op->type == JSON_OBJECT) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
struct json *error;
|
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
error = shash_find_data(json_object(op), "error");
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (error) {
|
|
|
|
|
if (error->type == JSON_STRING) {
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (!strcmp(error->string, "timed out")) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
soft_errors++;
|
2018-11-13 09:26:40 -08:00
|
|
|
|
} else if (!strcmp(error->string,
|
|
|
|
|
"unknown database")) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_flag_inconsistency(idl->cs);
|
2018-11-13 09:26:40 -08:00
|
|
|
|
soft_errors++;
|
2018-05-24 10:32:59 -07:00
|
|
|
|
} else if (!strcmp(error->string, "not owner")) {
|
2011-07-26 16:49:03 -07:00
|
|
|
|
lock_errors++;
|
2018-05-24 10:32:59 -07:00
|
|
|
|
} else if (!strcmp(error->string, "not allowed")) {
|
2017-05-31 19:04:32 -04:00
|
|
|
|
hard_errors++;
|
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, op);
|
2018-05-24 10:32:59 -07:00
|
|
|
|
} else if (strcmp(error->string, "aborted")) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
hard_errors++;
|
2010-02-05 14:11:12 -08:00
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, op);
|
2017-05-31 19:04:32 -04:00
|
|
|
|
VLOG_WARN_RL(&other_rl,
|
|
|
|
|
"transaction error: %s", txn->error);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
hard_errors++;
|
2010-02-05 14:11:12 -08:00
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, op);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl,
|
|
|
|
|
"\"error\" in reply is not JSON string");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
hard_errors++;
|
2010-02-05 14:11:12 -08:00
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, op);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl,
|
|
|
|
|
"operation reply is not JSON null or object");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-07-26 16:49:03 -07:00
|
|
|
|
if (!soft_errors && !hard_errors && !lock_errors) {
|
2010-01-28 13:23:30 -08:00
|
|
|
|
struct ovsdb_idl_txn_insert *insert;
|
|
|
|
|
|
|
|
|
|
if (txn->inc_table && !ovsdb_idl_txn_process_inc_reply(txn, ops)) {
|
|
|
|
|
hard_errors++;
|
|
|
|
|
}
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH (insert, hmap_node, &txn->inserted_rows) {
|
2010-01-28 13:23:30 -08:00
|
|
|
|
if (!ovsdb_idl_txn_process_insert_reply(insert, ops)) {
|
|
|
|
|
hard_errors++;
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-12-16 16:26:17 -08:00
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
status = (hard_errors ? TXN_ERROR
|
2011-07-26 16:49:03 -07:00
|
|
|
|
: lock_errors ? TXN_NOT_LOCKED
|
2012-03-27 10:16:52 -07:00
|
|
|
|
: soft_errors ? TXN_TRY_AGAIN
|
2009-12-07 17:08:04 -08:00
|
|
|
|
: TXN_SUCCESS);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ovsdb_idl_txn_complete(txn, status);
|
|
|
|
|
}
|
2009-12-08 17:14:56 -08:00
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns the transaction currently active for 'row''s IDL. A transaction
|
|
|
|
|
* must currently be active. */
|
2009-12-08 17:14:56 -08:00
|
|
|
|
struct ovsdb_idl_txn *
|
|
|
|
|
ovsdb_idl_txn_get(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
struct ovsdb_idl_txn *txn = row->table->idl->txn;
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(txn != NULL);
|
2009-12-08 17:14:56 -08:00
|
|
|
|
return txn;
|
|
|
|
|
}
|
2010-03-03 14:27:53 -08:00
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns the IDL on which 'txn' acts. */
|
2010-03-03 14:27:53 -08:00
|
|
|
|
struct ovsdb_idl *
|
|
|
|
|
ovsdb_idl_txn_get_idl (struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return txn->idl;
|
2010-03-03 14:27:53 -08:00
|
|
|
|
}
|
2015-08-04 14:49:11 -07:00
|
|
|
|
|
|
|
|
|
/* Blocks until 'idl' successfully connects to the remote database and
|
|
|
|
|
* retrieves its contents. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_get_initial_snapshot(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
while (1) {
|
|
|
|
|
ovsdb_idl_run(idl);
|
|
|
|
|
if (ovsdb_idl_has_ever_connected(idl)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_wait(idl);
|
|
|
|
|
poll_block();
|
|
|
|
|
}
|
|
|
|
|
}
|
2011-07-26 16:49:03 -07:00
|
|
|
|
|
|
|
|
|
/* If 'lock_name' is nonnull, configures 'idl' to obtain the named lock from
|
|
|
|
|
* the database server and to avoid modifying the database when the lock cannot
|
|
|
|
|
* be acquired (that is, when another client has the same lock).
|
|
|
|
|
*
|
|
|
|
|
* If 'lock_name' is NULL, drops the locking requirement and releases the
|
|
|
|
|
* lock. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_set_lock(struct ovsdb_idl *idl, const char *lock_name)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
ovsdb_cs_set_lock(idl->cs, lock_name);
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns true if 'idl' is configured to obtain a lock and owns that lock.
|
|
|
|
|
*
|
|
|
|
|
* Locking and unlocking happens asynchronously from the database client's
|
|
|
|
|
* point of view, so the information is only useful for optimization (e.g. if
|
|
|
|
|
* the client doesn't have the lock then there's no point in trying to write to
|
|
|
|
|
* the database). */
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_has_lock(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return ovsdb_cs_has_lock(idl->cs);
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns true if 'idl' is configured to obtain a lock but the database server
|
|
|
|
|
* has indicated that some other client already owns the requested lock. */
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_is_lock_contended(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2020-11-21 11:47:01 -08:00
|
|
|
|
return ovsdb_cs_is_lock_contended(idl->cs);
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
2015-08-04 09:52:26 -07:00
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
/* Inserts a new Map Operation into current transaction. */
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_add_map_op(struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum,
|
|
|
|
|
enum map_op_type op_type)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
|
|
|
|
struct map_op *map_op;
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
column_idx = column - class->columns;
|
|
|
|
|
|
|
|
|
|
/* Check if a map operation list exists for this column. */
|
|
|
|
|
if (!row->map_op_written) {
|
|
|
|
|
row->map_op_written = bitmap_allocate(class->n_columns);
|
|
|
|
|
row->map_op_lists = xzalloc(class->n_columns *
|
|
|
|
|
sizeof *row->map_op_lists);
|
|
|
|
|
}
|
|
|
|
|
if (!row->map_op_lists[column_idx]) {
|
|
|
|
|
row->map_op_lists[column_idx] = map_op_list_create();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add a map operation to the corresponding list. */
|
|
|
|
|
map_op = map_op_create(datum, op_type);
|
|
|
|
|
bitmap_set1(row->map_op_written, column_idx);
|
|
|
|
|
map_op_list_add(row->map_op_lists[column_idx], map_op, &column->type);
|
|
|
|
|
|
|
|
|
|
/* Add this row to transaction's list of rows. */
|
|
|
|
|
if (hmap_node_is_null(&row->txn_node)) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
hmap_insert(&row->table->idl->txn->txn_rows, &row->txn_node,
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
uuid_hash(&row->uuid));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
/* Inserts a new Set Operation into current transaction. */
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_add_set_op(struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum,
|
|
|
|
|
enum set_op_type op_type)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
|
|
|
|
struct set_op *set_op;
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
2016-08-06 17:46:29 -05:00
|
|
|
|
column_idx = column - class->columns;
|
|
|
|
|
|
|
|
|
|
/* Check if a set operation list exists for this column. */
|
|
|
|
|
if (!row->set_op_written) {
|
|
|
|
|
row->set_op_written = bitmap_allocate(class->n_columns);
|
|
|
|
|
row->set_op_lists = xzalloc(class->n_columns *
|
|
|
|
|
sizeof *row->set_op_lists);
|
|
|
|
|
}
|
|
|
|
|
if (!row->set_op_lists[column_idx]) {
|
|
|
|
|
row->set_op_lists[column_idx] = set_op_list_create();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add a set operation to the corresponding list. */
|
|
|
|
|
set_op = set_op_create(datum, op_type);
|
|
|
|
|
bitmap_set1(row->set_op_written, column_idx);
|
|
|
|
|
set_op_list_add(row->set_op_lists[column_idx], set_op, &column->type);
|
|
|
|
|
|
|
|
|
|
/* Add this row to the transactions's list of rows. */
|
|
|
|
|
if (hmap_node_is_null(&row->txn_node)) {
|
2020-11-21 11:47:01 -08:00
|
|
|
|
hmap_insert(&row->table->idl->txn->txn_rows, &row->txn_node,
|
2016-08-06 17:46:29 -05:00
|
|
|
|
uuid_hash(&row->uuid));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
static bool
|
|
|
|
|
is_valid_partial_update(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
/* Verify that this column is being monitored. */
|
2017-08-11 11:06:44 -07:00
|
|
|
|
unsigned int column_idx = column - row->table->class_->columns;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
if (!(row->table->modes[column_idx] & OVSDB_IDL_MONITOR)) {
|
|
|
|
|
VLOG_WARN("cannot partially update non-monitored column");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Verify that the update affects a single element. */
|
|
|
|
|
if (datum->n != 1) {
|
|
|
|
|
VLOG_WARN("invalid datum for partial update");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
/* Inserts the value described in 'datum' into the map in 'column' in
|
|
|
|
|
* 'row_'. If the value doesn't already exist in 'column' then it's value
|
|
|
|
|
* is added. The value in 'datum' must be of the same type as the values
|
|
|
|
|
* in 'column'. This function takes ownership of 'datum'.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "update"
|
|
|
|
|
* functions generated by vswitch-idl. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_write_partial_set(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
|
|
|
|
enum set_op_type op_type;
|
|
|
|
|
|
|
|
|
|
if (!is_valid_partial_update(row, column, datum)) {
|
|
|
|
|
ovsdb_datum_destroy(datum, &column->type);
|
|
|
|
|
free(datum);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
op_type = SET_OP_INSERT;
|
|
|
|
|
|
|
|
|
|
ovsdb_idl_txn_add_set_op(row, column, datum, op_type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Deletes the value specified in 'datum' from the set in 'column' in 'row_'.
|
|
|
|
|
* The value in 'datum' must be of the same type as the keys in 'column'.
|
|
|
|
|
* This function takes ownership of 'datum'.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "update"
|
|
|
|
|
* functions generated by vswitch-idl. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_delete_partial_set(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
|
|
|
|
|
|
|
|
|
if (!is_valid_partial_update(row, column, datum)) {
|
|
|
|
|
struct ovsdb_type type_ = column->type;
|
|
|
|
|
type_.value.type = OVSDB_TYPE_VOID;
|
|
|
|
|
ovsdb_datum_destroy(datum, &type_);
|
|
|
|
|
free(datum);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_txn_add_set_op(row, column, datum, SET_OP_DELETE);
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
/* Inserts the key-value specified in 'datum' into the map in 'column' in
|
|
|
|
|
* 'row_'. If the key already exist in 'column', then it's value is updated
|
|
|
|
|
* with the value in 'datum'. The key-value in 'datum' must be of the same type
|
|
|
|
|
* as the keys-values in 'column'. This function takes ownership of 'datum'.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "update"
|
|
|
|
|
* functions generated by vswitch-idl. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_write_partial_map(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
|
|
|
|
enum ovsdb_atomic_type key_type;
|
|
|
|
|
enum map_op_type op_type;
|
|
|
|
|
const struct ovsdb_datum *old_datum;
|
|
|
|
|
|
|
|
|
|
if (!is_valid_partial_update(row, column, datum)) {
|
|
|
|
|
ovsdb_datum_destroy(datum, &column->type);
|
2016-06-13 16:06:48 +00:00
|
|
|
|
free(datum);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Find out if this is an insert or an update. */
|
|
|
|
|
key_type = column->type.key.type;
|
|
|
|
|
old_datum = ovsdb_idl_read(row, column);
|
ovsdb-data: Optimize union of sets.
Current algorithm of ovsdb_datum_union looks like this:
for-each atom in b:
if not bin_search(a, atom):
push(a, clone(atom))
quicksort(a)
So, the complexity looks like this:
Nb * log2(Na) + Nb + (Na + Nb) * log2(Na + Nb)
Comparisons clones Comparisons for quicksort
for search
ovsdb_datum_union() is heavily used in database transactions while
new element is added to a set. For example, if new logical switch
port is added to a logical switch in OVN. This is a very common
use case where CMS adds one new port to an existing switch that
already has, let's say, 100 ports. For this case ovsdb-server will
have to perform:
1 * log2(100) + 1 clone + 101 * log2(101)
Comparisons Comparisons for
for search quicksort.
~7 1 ~707
Roughly 714 comparisons of atoms and 1 clone.
Since binary search can give us position, where new atom should go
(it's the 'low' index after the search completion) for free, the
logic can be re-worked like this:
copied = 0
for-each atom in b:
desired_position = bin_search(a, atom)
push(result, a[ copied : desired_position - 1 ])
copied = desired_position
push(result, clone(atom))
push(result, a[ copied : Na ])
swap(a, result)
Complexity of this schema:
Nb * log2(Na) + Nb + Na
Comparisons clones memory copy on push
for search
'swap' is just a swap of a few pointers. 'push' is not a 'clone',
but a simple memory copy of 'union ovsdb_atom'.
In general, this schema substitutes complexity of a quicksort
with complexity of a memory copy of Na atom structures, where we're
not even copying strings that these atoms are pointing to.
Complexity in the example above goes down from 714 comparisons
to 7 comparisons and memcpy of 100 * sizeof (union ovsdb_atom) bytes.
General complexity of a memory copy should always be lower than
complexity of a quicksort, especially because these copies usually
performed in bulk, so this new schema should work faster for any input.
All in all, this change allows to execute several times more
transactions per second for transactions that adds new entries to sets.
Alternatively, union can be implemented as a linear merge of two
sorted arrays, but this will result in O(Na) comparisons, which
is more than Nb * log2(Na) in common case, since Na is usually
far bigger than Nb. Linear merge will also mean per-atom memory
copies instead of copying in bulk.
'replace' functionality of ovsdb_datum_union() had no users, so it
just removed. But it can easily be added back if needed in the future.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Han Zhou <hzhou@ovn.org>
Acked-by: Mark D. Gray <mark.d.gray@redhat.com>
2021-09-23 01:47:22 +02:00
|
|
|
|
if (ovsdb_datum_find_key(old_datum, &datum->keys[0], key_type, NULL)) {
|
|
|
|
|
op_type = MAP_OP_UPDATE;
|
|
|
|
|
} else {
|
|
|
|
|
op_type = MAP_OP_INSERT;
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
|
|
|
|
|
ovsdb_idl_txn_add_map_op(row, column, datum, op_type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Deletes the key specified in 'datum' from the map in 'column' in 'row_'.
|
|
|
|
|
* The key in 'datum' must be of the same type as the keys in 'column'.
|
|
|
|
|
* The value in 'datum' must be NULL. This function takes ownership of
|
|
|
|
|
* 'datum'.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "update"
|
|
|
|
|
* functions generated by vswitch-idl. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_delete_partial_map(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
|
|
|
|
|
|
|
|
|
if (!is_valid_partial_update(row, column, datum)) {
|
|
|
|
|
struct ovsdb_type type_ = column->type;
|
|
|
|
|
type_.value.type = OVSDB_TYPE_VOID;
|
|
|
|
|
ovsdb_datum_destroy(datum, &type_);
|
2016-06-13 16:06:48 +00:00
|
|
|
|
free(datum);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_txn_add_map_op(row, column, datum, MAP_OP_DELETE);
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-04 09:52:26 -07:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_loop_destroy(struct ovsdb_idl_loop *loop)
|
|
|
|
|
{
|
|
|
|
|
if (loop) {
|
|
|
|
|
ovsdb_idl_destroy(loop->idl);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_txn *
|
|
|
|
|
ovsdb_idl_loop_run(struct ovsdb_idl_loop *loop)
|
|
|
|
|
{
|
|
|
|
|
ovsdb_idl_run(loop->idl);
|
2020-06-05 14:00:29 +05:30
|
|
|
|
|
|
|
|
|
/* See if we can commit the loop->committing_txn. */
|
|
|
|
|
if (loop->committing_txn) {
|
|
|
|
|
ovsdb_idl_try_commit_loop_txn(loop, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-04 09:52:26 -07:00
|
|
|
|
loop->open_txn = (loop->committing_txn
|
|
|
|
|
|| ovsdb_idl_get_seqno(loop->idl) == loop->skip_seqno
|
|
|
|
|
? NULL
|
|
|
|
|
: ovsdb_idl_txn_create(loop->idl));
|
2020-05-15 09:36:37 -07:00
|
|
|
|
if (loop->open_txn) {
|
|
|
|
|
ovsdb_idl_txn_add_comment(loop->open_txn, "%s", program_name);
|
|
|
|
|
}
|
2015-08-04 09:52:26 -07:00
|
|
|
|
return loop->open_txn;
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-05 14:00:29 +05:30
|
|
|
|
/* Attempts to commit the current transaction, if one is open.
|
|
|
|
|
*
|
|
|
|
|
* If a transaction was open, in this or a previous iteration of the main loop,
|
|
|
|
|
* and had not before finished committing (successfully or unsuccessfully), the
|
|
|
|
|
* return value is one of:
|
|
|
|
|
*
|
|
|
|
|
* 1: The transaction committed successfully (or it did not change anything in
|
|
|
|
|
* the database).
|
|
|
|
|
* 0: The transaction failed.
|
|
|
|
|
* -1: The commit is still in progress.
|
|
|
|
|
*
|
|
|
|
|
* Thus, the return value is -1 if the transaction is in progress and otherwise
|
|
|
|
|
* true for success, false for failure.
|
|
|
|
|
*
|
|
|
|
|
* (In the corner case where the IDL sends a transaction to the database and
|
|
|
|
|
* the database commits it, and the connection between the IDL and the database
|
|
|
|
|
* drops before the IDL receives the message confirming the commit, this
|
|
|
|
|
* function can return 0 even though the transaction succeeded.)
|
|
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
ovsdb_idl_try_commit_loop_txn(struct ovsdb_idl_loop *loop,
|
|
|
|
|
bool *may_need_wakeup)
|
|
|
|
|
{
|
|
|
|
|
if (!loop->committing_txn) {
|
|
|
|
|
/* Not a meaningful return value: no transaction was in progress. */
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int retval;
|
|
|
|
|
struct ovsdb_idl_txn *txn = loop->committing_txn;
|
|
|
|
|
|
|
|
|
|
enum ovsdb_idl_txn_status status = ovsdb_idl_txn_commit(txn);
|
|
|
|
|
if (status != TXN_INCOMPLETE) {
|
|
|
|
|
switch (status) {
|
|
|
|
|
case TXN_TRY_AGAIN:
|
|
|
|
|
/* We want to re-evaluate the database when it's changed from
|
|
|
|
|
* the contents that it had when we started the commit. (That
|
|
|
|
|
* might have already happened.) */
|
|
|
|
|
loop->skip_seqno = loop->precommit_seqno;
|
|
|
|
|
if (ovsdb_idl_get_seqno(loop->idl) != loop->skip_seqno
|
|
|
|
|
&& may_need_wakeup) {
|
|
|
|
|
*may_need_wakeup = true;
|
|
|
|
|
}
|
|
|
|
|
retval = 0;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case TXN_SUCCESS:
|
|
|
|
|
/* Possibly some work on the database was deferred because no
|
|
|
|
|
* further transaction could proceed. Wake up again. */
|
|
|
|
|
retval = 1;
|
|
|
|
|
loop->cur_cfg = loop->next_cfg;
|
|
|
|
|
if (may_need_wakeup) {
|
|
|
|
|
*may_need_wakeup = true;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case TXN_UNCHANGED:
|
|
|
|
|
retval = 1;
|
|
|
|
|
loop->cur_cfg = loop->next_cfg;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case TXN_ABORTED:
|
|
|
|
|
case TXN_NOT_LOCKED:
|
|
|
|
|
case TXN_ERROR:
|
|
|
|
|
retval = 0;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case TXN_UNCOMMITTED:
|
|
|
|
|
case TXN_INCOMPLETE:
|
|
|
|
|
default:
|
|
|
|
|
OVS_NOT_REACHED();
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_txn_destroy(txn);
|
|
|
|
|
loop->committing_txn = NULL;
|
|
|
|
|
} else {
|
|
|
|
|
retval = -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-21 22:16:19 -07:00
|
|
|
|
/* Attempts to commit the current transaction, if one is open, and sets up the
|
|
|
|
|
* poll loop to wake up when some more work might be needed.
|
|
|
|
|
*
|
|
|
|
|
* If a transaction was open, in this or a previous iteration of the main loop,
|
|
|
|
|
* and had not before finished committing (successfully or unsuccessfully), the
|
|
|
|
|
* return value is one of:
|
|
|
|
|
*
|
|
|
|
|
* 1: The transaction committed successfully (or it did not change anything in
|
|
|
|
|
* the database).
|
|
|
|
|
* 0: The transaction failed.
|
|
|
|
|
* -1: The commit is still in progress.
|
|
|
|
|
*
|
|
|
|
|
* Thus, the return value is -1 if the transaction is in progress and otherwise
|
|
|
|
|
* true for success, false for failure.
|
|
|
|
|
*
|
|
|
|
|
* (In the corner case where the IDL sends a transaction to the database and
|
|
|
|
|
* the database commits it, and the connection between the IDL and the database
|
|
|
|
|
* drops before the IDL receives the message confirming the commit, this
|
|
|
|
|
* function can return 0 even though the transaction succeeded.)
|
|
|
|
|
*/
|
|
|
|
|
int
|
2015-08-04 09:52:26 -07:00
|
|
|
|
ovsdb_idl_loop_commit_and_wait(struct ovsdb_idl_loop *loop)
|
|
|
|
|
{
|
|
|
|
|
if (loop->open_txn) {
|
|
|
|
|
loop->committing_txn = loop->open_txn;
|
|
|
|
|
loop->open_txn = NULL;
|
|
|
|
|
|
|
|
|
|
loop->precommit_seqno = ovsdb_idl_get_seqno(loop->idl);
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-05 14:00:29 +05:30
|
|
|
|
bool may_need_wakeup = false;
|
|
|
|
|
int retval = ovsdb_idl_try_commit_loop_txn(loop, &may_need_wakeup);
|
|
|
|
|
if (may_need_wakeup) {
|
|
|
|
|
poll_immediate_wake();
|
2015-08-04 09:52:26 -07:00
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_wait(loop->idl);
|
2016-09-21 22:16:19 -07:00
|
|
|
|
|
|
|
|
|
return retval;
|
2015-08-04 09:52:26 -07:00
|
|
|
|
}
|