2
0
mirror of https://github.com/openvswitch/ovs synced 2025-08-22 09:58:01 +00:00
ovs/ovsdb/execution.c

895 lines
30 KiB
C
Raw Permalink Normal View History

/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2017, 2019 Nicira, Inc.
2009-11-04 15:11:44 -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.h"
2009-11-04 15:11:44 -08:00
#include <limits.h>
#include "column.h"
#include "condition.h"
#include "file.h"
#include "openvswitch/json.h"
#include "mutation.h"
2009-11-04 15:11:44 -08:00
#include "ovsdb-data.h"
#include "ovsdb-error.h"
#include "ovsdb-parser.h"
#include "query.h"
#include "rbac.h"
2009-11-04 15:11:44 -08:00
#include "row.h"
#include "server.h"
2009-11-04 15:11:44 -08:00
#include "table.h"
#include "timeval.h"
#include "transaction.h"
struct ovsdb_execution {
struct ovsdb *db;
const struct ovsdb_session *session;
2009-11-04 15:11:44 -08:00
struct ovsdb_txn *txn;
struct ovsdb_symbol_table *symtab;
bool durable;
const char *role;
const char *id;
2009-11-04 15:11:44 -08:00
/* Triggers. */
long long int elapsed_msec;
long long int timeout_msec;
};
typedef struct ovsdb_error *ovsdb_operation_executor(struct ovsdb_execution *,
struct ovsdb_parser *,
struct json *result);
static ovsdb_operation_executor ovsdb_execute_insert;
static ovsdb_operation_executor ovsdb_execute_select;
static ovsdb_operation_executor ovsdb_execute_update;
static ovsdb_operation_executor ovsdb_execute_mutate;
2009-11-04 15:11:44 -08:00
static ovsdb_operation_executor ovsdb_execute_delete;
static ovsdb_operation_executor ovsdb_execute_wait;
static ovsdb_operation_executor ovsdb_execute_commit;
static ovsdb_operation_executor ovsdb_execute_abort;
static ovsdb_operation_executor ovsdb_execute_comment;
static ovsdb_operation_executor ovsdb_execute_assert;
2009-11-04 15:11:44 -08:00
static ovsdb_operation_executor *
lookup_executor(const char *name, bool *read_only)
2009-11-04 15:11:44 -08:00
{
struct ovsdb_operation {
const char *name;
bool read_only;
2009-11-04 15:11:44 -08:00
ovsdb_operation_executor *executor;
};
static const struct ovsdb_operation operations[] = {
{ "insert", false, ovsdb_execute_insert },
{ "select", true, ovsdb_execute_select },
{ "update", false, ovsdb_execute_update },
{ "mutate", false, ovsdb_execute_mutate },
{ "delete", false, ovsdb_execute_delete },
{ "wait", true, ovsdb_execute_wait },
{ "commit", false, ovsdb_execute_commit },
{ "abort", true, ovsdb_execute_abort },
{ "comment", true, ovsdb_execute_comment },
{ "assert", true, ovsdb_execute_assert },
2009-11-04 15:11:44 -08:00
};
size_t i;
for (i = 0; i < ARRAY_SIZE(operations); i++) {
const struct ovsdb_operation *c = &operations[i];
if (!strcmp(c->name, name)) {
*read_only = c->read_only;
2009-11-04 15:11:44 -08:00
return c->executor;
}
}
return NULL;
}
/* On success, returns a transaction and stores the results to return to the
ovsdb: relay: Add support for transaction forwarding. Current version of ovsdb relay allows to scale out read-only access to the primary database. However, many clients are not read-only but read-mostly. For example, ovn-controller. In order to scale out database access for this case ovsdb-server need to process transactions that are not read-only. Relay is not allowed to do that, i.e. not allowed to modify the database, but it can act like a proxy and forward transactions that includes database modifications to the primary server and forward replies back to a client. At the same time it may serve read-only transactions and monitor requests by itself greatly reducing the load on primary server. This configuration will slightly increase transaction latency, but it's not very important for read-mostly use cases. Implementation details: With this change instead of creating a trigger to commit the transaction, ovsdb-server will create a trigger for transaction forwarding. Later, ovsdb_relay_run() will send all new transactions to the relay source. Once transaction reply received from the relay source, ovsdb-relay module will update the state of the transaction forwarding with the reply. After that, trigger_run() will complete the trigger and jsonrpc_server_run() will send the reply back to the client. Since transaction reply from the relay source will be received after all the updates, client will receive all the updates before receiving the transaction reply as it is in a normal scenario with other database models. Acked-by: Mark D. Gray <mark.d.gray@redhat.com> Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-15 19:05:40 +02:00
* client in '*resultsp'. If 'forwarding_needed' is nonnull and transaction
* needs to be forwarded (in relay mode), sets '*forwarding_needed' to true.
*
* On failure, returns NULL. If '*resultsp' is nonnull, then it is the results
* to return to the client. If '*resultsp' is null, then the execution failed
* due to an unsatisfied "wait" operation and '*timeout_msec' is the time at
* which the transaction will time out. (If 'timeout_msec' is null, this case
* never occurs--instead, an unsatisfied "wait" unconditionally fails.) */
struct ovsdb_txn *
ovsdb_execute_compose(struct ovsdb *db, const struct ovsdb_session *session,
const struct json *params, bool read_only,
const char *role, const char *id,
long long int elapsed_msec, long long int *timeout_msec,
ovsdb: relay: Add support for transaction forwarding. Current version of ovsdb relay allows to scale out read-only access to the primary database. However, many clients are not read-only but read-mostly. For example, ovn-controller. In order to scale out database access for this case ovsdb-server need to process transactions that are not read-only. Relay is not allowed to do that, i.e. not allowed to modify the database, but it can act like a proxy and forward transactions that includes database modifications to the primary server and forward replies back to a client. At the same time it may serve read-only transactions and monitor requests by itself greatly reducing the load on primary server. This configuration will slightly increase transaction latency, but it's not very important for read-mostly use cases. Implementation details: With this change instead of creating a trigger to commit the transaction, ovsdb-server will create a trigger for transaction forwarding. Later, ovsdb_relay_run() will send all new transactions to the relay source. Once transaction reply received from the relay source, ovsdb-relay module will update the state of the transaction forwarding with the reply. After that, trigger_run() will complete the trigger and jsonrpc_server_run() will send the reply back to the client. Since transaction reply from the relay source will be received after all the updates, client will receive all the updates before receiving the transaction reply as it is in a normal scenario with other database models. Acked-by: Mark D. Gray <mark.d.gray@redhat.com> Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-15 19:05:40 +02:00
bool *durable, bool *forwarding_needed,
struct json **resultsp)
2009-11-04 15:11:44 -08:00
{
struct ovsdb_execution x;
struct ovsdb_error *error;
struct json *results;
size_t n_operations;
size_t i;
*durable = false;
ovsdb: relay: Add support for transaction forwarding. Current version of ovsdb relay allows to scale out read-only access to the primary database. However, many clients are not read-only but read-mostly. For example, ovn-controller. In order to scale out database access for this case ovsdb-server need to process transactions that are not read-only. Relay is not allowed to do that, i.e. not allowed to modify the database, but it can act like a proxy and forward transactions that includes database modifications to the primary server and forward replies back to a client. At the same time it may serve read-only transactions and monitor requests by itself greatly reducing the load on primary server. This configuration will slightly increase transaction latency, but it's not very important for read-mostly use cases. Implementation details: With this change instead of creating a trigger to commit the transaction, ovsdb-server will create a trigger for transaction forwarding. Later, ovsdb_relay_run() will send all new transactions to the relay source. Once transaction reply received from the relay source, ovsdb-relay module will update the state of the transaction forwarding with the reply. After that, trigger_run() will complete the trigger and jsonrpc_server_run() will send the reply back to the client. Since transaction reply from the relay source will be received after all the updates, client will receive all the updates before receiving the transaction reply as it is in a normal scenario with other database models. Acked-by: Mark D. Gray <mark.d.gray@redhat.com> Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-15 19:05:40 +02:00
if (forwarding_needed) {
*forwarding_needed = false;
}
if (params->type != JSON_ARRAY
|| !json_array_size(params)
|| json_array_at(params, 0)->type != JSON_STRING
|| strcmp(json_string(json_array_at(params, 0)), db->schema->name)) {
if (params->type != JSON_ARRAY) {
error = ovsdb_syntax_error(params, NULL, "array expected");
} else {
error = ovsdb_syntax_error(params, NULL, "database name expected "
"as first parameter");
}
*resultsp = ovsdb_error_to_json_free(error);
return NULL;
2009-11-04 15:11:44 -08:00
}
x.db = db;
x.session = session;
2009-11-04 15:11:44 -08:00
x.txn = ovsdb_txn_create(db);
x.symtab = ovsdb_symbol_table_create();
x.durable = false;
x.role = role;
x.id = id;
2009-11-04 15:11:44 -08:00
x.elapsed_msec = elapsed_msec;
x.timeout_msec = LLONG_MAX;
results = NULL;
results = json_array_create_empty();
n_operations = json_array_size(params) - 1;
2009-11-04 15:11:44 -08:00
error = NULL;
for (i = 1; i <= n_operations; i++) {
const struct json *operation = json_array_at(params, i);
2009-11-04 15:11:44 -08:00
struct ovsdb_error *parse_error;
struct ovsdb_parser parser;
struct json *result;
const struct json *op;
const char *op_name = NULL;
bool ro = false;
2009-11-04 15:11:44 -08:00
/* Parse and execute operation. */
ovsdb_parser_init(&parser, operation,
"ovsdb operation %"PRIuSIZE" of %"PRIuSIZE, i,
n_operations);
2009-11-04 15:11:44 -08:00
op = ovsdb_parser_member(&parser, "op", OP_ID);
result = json_object_create();
if (op) {
op_name = json_string(op);
ovsdb_operation_executor *executor = lookup_executor(op_name, &ro);
2009-11-04 15:11:44 -08:00
if (executor) {
error = executor(&x, &parser, result);
} else {
ovsdb_parser_raise_error(&parser, "No operation \"%s\"",
op_name);
2009-11-04 15:11:44 -08:00
}
} else {
ovs_assert(ovsdb_parser_has_error(&parser));
2009-11-04 15:11:44 -08:00
}
/* A parse error overrides any other error.
* An error overrides any other result. */
parse_error = ovsdb_parser_finish(&parser);
if (parse_error) {
ovsdb_error_destroy(error);
error = parse_error;
}
/* Create read-only violation error if there is one. */
if (!ro && !error) {
if (read_only) {
error = ovsdb_error("not allowed",
"%s operation not allowed when "
"database server is in read only mode",
op_name);
} else if (db->schema->name[0] == '_') {
error = ovsdb_error("not allowed",
"%s operation not allowed on "
"table in reserved database %s",
op_name, db->schema->name);
ovsdb: relay: Add support for transaction forwarding. Current version of ovsdb relay allows to scale out read-only access to the primary database. However, many clients are not read-only but read-mostly. For example, ovn-controller. In order to scale out database access for this case ovsdb-server need to process transactions that are not read-only. Relay is not allowed to do that, i.e. not allowed to modify the database, but it can act like a proxy and forward transactions that includes database modifications to the primary server and forward replies back to a client. At the same time it may serve read-only transactions and monitor requests by itself greatly reducing the load on primary server. This configuration will slightly increase transaction latency, but it's not very important for read-mostly use cases. Implementation details: With this change instead of creating a trigger to commit the transaction, ovsdb-server will create a trigger for transaction forwarding. Later, ovsdb_relay_run() will send all new transactions to the relay source. Once transaction reply received from the relay source, ovsdb-relay module will update the state of the transaction forwarding with the reply. After that, trigger_run() will complete the trigger and jsonrpc_server_run() will send the reply back to the client. Since transaction reply from the relay source will be received after all the updates, client will receive all the updates before receiving the transaction reply as it is in a normal scenario with other database models. Acked-by: Mark D. Gray <mark.d.gray@redhat.com> Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-15 19:05:40 +02:00
} else if (db->is_relay && forwarding_needed) {
*forwarding_needed = true;
}
}
2009-11-04 15:11:44 -08:00
if (error) {
json_destroy(result);
json_array_add(results, ovsdb_error_to_json(error));
if (!strcmp(ovsdb_error_get_tag(error), "not supported")
&& timeout_msec) {
*timeout_msec = x.timeout_msec;
json_destroy(results);
results = NULL;
goto exit;
}
break;
2009-11-04 15:11:44 -08:00
}
json_array_add(results, result);
2009-11-04 15:11:44 -08:00
}
while (json_array_size(results) < n_operations) {
2009-11-04 15:11:44 -08:00
json_array_add(results, json_null_create());
}
exit:
if (error) {
ovsdb_txn_abort(x.txn);
x.txn = NULL;
ovsdb_error_destroy(error);
}
*resultsp = results;
*durable = x.durable;
2009-11-04 15:11:44 -08:00
ovsdb_symbol_table_destroy(x.symtab);
return x.txn;
}
struct json *
ovsdb_execute(struct ovsdb *db, const struct ovsdb_session *session,
const struct json *params, bool read_only,
const char *role, const char *id,
long long int elapsed_msec, long long int *timeout_msec)
{
bool durable;
struct json *results;
struct ovsdb_txn *txn = ovsdb_execute_compose(
db, session, params, read_only, role, id, elapsed_msec, timeout_msec,
ovsdb: relay: Add support for transaction forwarding. Current version of ovsdb relay allows to scale out read-only access to the primary database. However, many clients are not read-only but read-mostly. For example, ovn-controller. In order to scale out database access for this case ovsdb-server need to process transactions that are not read-only. Relay is not allowed to do that, i.e. not allowed to modify the database, but it can act like a proxy and forward transactions that includes database modifications to the primary server and forward replies back to a client. At the same time it may serve read-only transactions and monitor requests by itself greatly reducing the load on primary server. This configuration will slightly increase transaction latency, but it's not very important for read-mostly use cases. Implementation details: With this change instead of creating a trigger to commit the transaction, ovsdb-server will create a trigger for transaction forwarding. Later, ovsdb_relay_run() will send all new transactions to the relay source. Once transaction reply received from the relay source, ovsdb-relay module will update the state of the transaction forwarding with the reply. After that, trigger_run() will complete the trigger and jsonrpc_server_run() will send the reply back to the client. Since transaction reply from the relay source will be received after all the updates, client will receive all the updates before receiving the transaction reply as it is in a normal scenario with other database models. Acked-by: Mark D. Gray <mark.d.gray@redhat.com> Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-15 19:05:40 +02:00
&durable, NULL, &results);
if (!txn) {
return results;
}
struct ovsdb_error *error = ovsdb_txn_propose_commit_block(txn, durable);
if (error) {
json_array_add(results, ovsdb_error_to_json(error));
ovsdb_error_destroy(error);
}
2009-11-04 15:11:44 -08:00
return results;
}
static struct ovsdb_error *
2009-11-04 15:11:44 -08:00
ovsdb_execute_commit(struct ovsdb_execution *x, struct ovsdb_parser *parser,
struct json *result OVS_UNUSED)
2009-11-04 15:11:44 -08:00
{
const struct json *durable;
durable = ovsdb_parser_member(parser, "durable", OP_BOOLEAN);
if (durable && json_boolean(durable)) {
x->durable = true;
}
return NULL;
}
static struct ovsdb_error *
ovsdb_execute_abort(struct ovsdb_execution *x OVS_UNUSED,
struct ovsdb_parser *parser OVS_UNUSED,
struct json *result OVS_UNUSED)
2009-11-04 15:11:44 -08:00
{
return ovsdb_error("aborted", "aborted by request");
}
static struct ovsdb_table *
parse_table(struct ovsdb_execution *x,
struct ovsdb_parser *parser, const char *member)
{
struct ovsdb_table *table;
const char *table_name;
const struct json *json;
json = ovsdb_parser_member(parser, member, OP_ID);
if (!json) {
return NULL;
}
table_name = json_string(json);
table = shash_find_data(&x->db->tables, table_name);
if (!table) {
ovsdb_parser_raise_error(parser, "No table named %s.", table_name);
}
return table;
}
static OVS_WARN_UNUSED_RESULT struct ovsdb_error *
parse_row(const struct json *json, const struct ovsdb_table *table,
struct ovsdb_symbol_table *symtab,
2009-11-04 15:11:44 -08:00
struct ovsdb_row **rowp, struct ovsdb_column_set *columns)
{
struct ovsdb_error *error;
struct ovsdb_row *row;
*rowp = NULL;
if (!table) {
return OVSDB_BUG("null table");
}
if (!json) {
return OVSDB_BUG("null row");
2009-11-04 15:11:44 -08:00
}
row = ovsdb_row_create(table);
error = ovsdb_row_from_json(row, json, symtab, columns, false);
2009-11-04 15:11:44 -08:00
if (error) {
ovsdb_row_destroy(row);
return error;
} else {
*rowp = row;
return NULL;
}
}
static struct ovsdb_error *
2009-11-04 15:11:44 -08:00
ovsdb_execute_insert(struct ovsdb_execution *x, struct ovsdb_parser *parser,
struct json *result)
{
struct ovsdb_table *table;
struct ovsdb_row *row = NULL;
const struct json *uuid_json, *uuid_name, *row_json;
2009-11-04 15:11:44 -08:00
struct ovsdb_error *error;
struct uuid row_uuid;
2009-11-04 15:11:44 -08:00
table = parse_table(x, parser, "table");
uuid_json = ovsdb_parser_member(parser, "uuid", OP_STRING | OP_OPTIONAL);
2009-11-04 15:11:44 -08:00
uuid_name = ovsdb_parser_member(parser, "uuid-name", OP_ID | OP_OPTIONAL);
row_json = ovsdb_parser_member(parser, "row", OP_OBJECT);
2009-11-04 15:11:44 -08:00
error = ovsdb_parser_get_error(parser);
if (error) {
return error;
}
if (uuid_json) {
if (!uuid_from_string(&row_uuid, json_string(uuid_json))) {
return ovsdb_syntax_error(uuid_json, NULL, "bad uuid");
}
if (!ovsdb_txn_may_create_row(table, &row_uuid)) {
return ovsdb_syntax_error(uuid_json, "duplicate uuid",
"This UUID would duplicate a UUID "
"already present within the table or "
"deleted within the same transaction.");
}
}
if (uuid_name) {
struct ovsdb_symbol *symbol;
symbol = ovsdb_symbol_table_insert(x->symtab, json_string(uuid_name));
if (symbol->created) {
return ovsdb_syntax_error(uuid_name, "duplicate uuid-name",
"This \"uuid-name\" appeared on an "
"earlier \"insert\" operation.");
}
if (uuid_json) {
symbol->uuid = row_uuid;
} else {
row_uuid = symbol->uuid;
}
symbol->created = true;
} else if (!uuid_json) {
uuid_generate(&row_uuid);
}
2009-11-04 15:11:44 -08:00
if (!error) {
error = parse_row(row_json, table, x->symtab, &row, NULL);
2009-11-04 15:11:44 -08:00
}
2010-02-08 14:09:36 -08:00
if (!error) {
/* Check constraints for columns not included in "row", in case the
* default values do not satisfy the constraints. We could check only
* the columns that have their default values by supplying an
* ovsdb_column_set to parse_row() above, but I suspect that this is
* cheaper. */
const struct shash_node *node;
SHASH_FOR_EACH (node, &table->schema->columns) {
const struct ovsdb_column *column = node->data;
const struct ovsdb_datum *datum = &row->fields[column->index];
/* If there are 0 keys or pairs, there's nothing to check.
* If there is 1, it might be a default value.
* If there are more, it can't be a default value, so the value has
* already been checked. */
if (datum->n == 1) {
error = ovsdb_datum_check_constraints(datum, &column->type);
if (error) {
break;
}
}
}
}
if (!error && !ovsdb_rbac_insert(x->db, table, row, x->role, x->id)) {
error = ovsdb_perm_error("RBAC rules for client \"%s\" role \"%s\" "
"prohibit row insertion into table \"%s\".",
x->id, x->role, table->schema->name);
}
2009-11-04 15:11:44 -08:00
if (!error) {
*ovsdb_row_get_uuid_rw(row) = row_uuid;
2009-11-04 15:11:44 -08:00
ovsdb_txn_row_insert(x->txn, row);
json_object_put(result, "uuid",
ovsdb_datum_to_json(&row->fields[OVSDB_COL_UUID],
&ovsdb_type_uuid));
} else {
ovsdb_row_destroy(row);
2009-11-04 15:11:44 -08:00
}
return error;
}
static struct ovsdb_error *
2009-11-04 15:11:44 -08:00
ovsdb_execute_select(struct ovsdb_execution *x, struct ovsdb_parser *parser,
struct json *result)
{
struct ovsdb_table *table;
const struct json *where, *columns_json, *sort_json;
struct ovsdb_condition condition = OVSDB_CONDITION_INITIALIZER(&condition);
2009-11-04 15:11:44 -08:00
struct ovsdb_column_set columns = OVSDB_COLUMN_SET_INITIALIZER;
struct ovsdb_column_set sort = OVSDB_COLUMN_SET_INITIALIZER;
struct ovsdb_error *error;
table = parse_table(x, parser, "table");
where = ovsdb_parser_member(parser, "where", OP_ARRAY);
columns_json = ovsdb_parser_member(parser, "columns",
OP_ARRAY | OP_OPTIONAL);
sort_json = ovsdb_parser_member(parser, "sort", OP_ARRAY | OP_OPTIONAL);
error = ovsdb_parser_get_error(parser);
if (!error) {
error = ovsdb_condition_from_json(table->schema, where, x->symtab,
&condition);
}
if (!error) {
error = ovsdb_column_set_from_json(columns_json, table->schema,
&columns);
2009-11-04 15:11:44 -08:00
}
if (!error) {
error = ovsdb_column_set_from_json(sort_json, table->schema, &sort);
2009-11-04 15:11:44 -08:00
}
if (!error) {
struct ovsdb_row_set rows = OVSDB_ROW_SET_INITIALIZER;
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
ovsdb_query_distinct(table, &condition, &columns, &rows, x->txn);
2009-11-04 15:11:44 -08:00
ovsdb_row_set_sort(&rows, &sort);
json_object_put(result, "rows",
ovsdb_row_set_to_json(&rows, &columns));
ovsdb_row_set_destroy(&rows);
}
ovsdb_column_set_destroy(&columns);
ovsdb_column_set_destroy(&sort);
ovsdb_condition_destroy(&condition);
return error;
}
struct update_row_cbdata {
size_t n_matches;
struct ovsdb_txn *txn;
const struct ovsdb_row *row;
const struct ovsdb_column_set *columns;
const char *role;
const char *id;
2009-11-04 15:11:44 -08:00
};
static bool
update_row_cb(const struct ovsdb_row *row, void *ur_)
{
struct update_row_cbdata *ur = ur_;
ur->n_matches++;
if (!ovsdb_row_equal_columns(row, ur->row, ur->columns)) {
struct ovsdb_row *rw_row;
ovsdb_txn_row_modify(ur->txn, row, &rw_row, NULL);
ovsdb_error_assert(ovsdb_row_update_columns(
rw_row, ur->row, ur->columns, false));
2009-11-04 15:11:44 -08:00
}
return true;
}
static struct ovsdb_error *
2009-11-04 15:11:44 -08:00
ovsdb_execute_update(struct ovsdb_execution *x, struct ovsdb_parser *parser,
struct json *result)
{
struct ovsdb_table *table;
const struct json *where, *row_json;
struct ovsdb_condition condition = OVSDB_CONDITION_INITIALIZER(&condition);
2009-11-04 15:11:44 -08:00
struct ovsdb_column_set columns = OVSDB_COLUMN_SET_INITIALIZER;
struct ovsdb_row *row = NULL;
struct update_row_cbdata ur;
struct ovsdb_error *error;
table = parse_table(x, parser, "table");
where = ovsdb_parser_member(parser, "where", OP_ARRAY);
row_json = ovsdb_parser_member(parser, "row", OP_OBJECT);
2009-11-04 15:11:44 -08:00
error = ovsdb_parser_get_error(parser);
if (!error) {
error = parse_row(row_json, table, x->symtab, &row, &columns);
2009-11-04 15:11:44 -08:00
}
if (!error) {
size_t i;
for (i = 0; i < columns.n_columns; i++) {
const struct ovsdb_column *column = columns.columns[i];
if (!column->mutable) {
error = ovsdb_syntax_error(parser->json,
"constraint violation",
"Cannot update immutable column %s "
"in table %s.",
column->name, table->schema->name);
break;
}
}
}
2009-11-04 15:11:44 -08:00
if (!error) {
error = ovsdb_condition_from_json(table->schema, where, x->symtab,
&condition);
}
if (!error) {
ur.n_matches = 0;
ur.txn = x->txn;
ur.row = row;
ur.columns = &columns;
if (ovsdb_rbac_update(x->db, table, &columns, &condition, x->role,
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
x->id, x->txn)) {
ovsdb_query(table, &condition, update_row_cb, &ur, x->txn);
} else {
error = ovsdb_perm_error("RBAC rules for client \"%s\" role "
"\"%s\" prohibit modification of "
"table \"%s\".",
x->id, x->role, table->schema->name);
}
2009-11-04 15:11:44 -08:00
json_object_put(result, "count", json_integer_create(ur.n_matches));
}
ovsdb_row_destroy(row);
ovsdb_column_set_destroy(&columns);
ovsdb_condition_destroy(&condition);
return error;
}
struct mutate_row_cbdata {
size_t n_matches;
struct ovsdb_txn *txn;
const struct ovsdb_mutation_set *mutations;
struct ovsdb_error **error;
};
static bool
mutate_row_cb(const struct ovsdb_row *row, void *mr_)
{
struct mutate_row_cbdata *mr = mr_;
struct ovsdb_row *rw_row;
/* Not trying to track the row diff here, because user transactions
* may attempt to add duplicates or remove elements that do not exist. */
ovsdb_txn_row_modify(mr->txn, row, &rw_row, NULL);
mr->n_matches++;
*mr->error = ovsdb_mutation_set_execute(rw_row, mr->mutations);
return *mr->error == NULL;
}
static bool
count_row_cb(const struct ovsdb_row *row OVS_UNUSED, void *rc)
{
size_t *row_count = rc;
(*row_count)++;
return true;
}
static struct ovsdb_error *
ovsdb_execute_mutate(struct ovsdb_execution *x, struct ovsdb_parser *parser,
struct json *result)
{
struct ovsdb_table *table;
const struct json *where;
const struct json *mutations_json;
struct ovsdb_condition condition = OVSDB_CONDITION_INITIALIZER(&condition);
struct ovsdb_mutation_set mutations = OVSDB_MUTATION_SET_INITIALIZER;
struct mutate_row_cbdata mr;
struct ovsdb_error *error;
table = parse_table(x, parser, "table");
where = ovsdb_parser_member(parser, "where", OP_ARRAY);
mutations_json = ovsdb_parser_member(parser, "mutations", OP_ARRAY);
error = ovsdb_parser_get_error(parser);
if (!error) {
error = ovsdb_mutation_set_from_json(table->schema, mutations_json,
x->symtab, &mutations);
}
if (!error) {
error = ovsdb_condition_from_json(table->schema, where, x->symtab,
&condition);
}
if (!error && ovsdb_mutation_set_empty(&mutations)) {
/* Special case with no mutations, just return the row count. */
if (ovsdb_condition_empty(&condition)) {
json_object_put(result, "count",
json_integer_create(hmap_count(&table->rows)));
} else {
size_t row_count = 0;
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
ovsdb_query(table, &condition, count_row_cb, &row_count, x->txn);
json_object_put(result, "count",
json_integer_create(row_count));
}
} else if (!error) {
mr.n_matches = 0;
mr.txn = x->txn;
mr.mutations = &mutations;
mr.error = &error;
if (ovsdb_rbac_mutate(x->db, table, &mutations, &condition, x->role,
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
x->id, x->txn)) {
ovsdb_query(table, &condition, mutate_row_cb, &mr, x->txn);
} else {
error = ovsdb_perm_error("RBAC rules for client \"%s\" role "
"\"%s\" prohibit mutate operation on "
"table \"%s\".",
x->id, x->role, table->schema->name);
}
json_object_put(result, "count", json_integer_create(mr.n_matches));
}
ovsdb_mutation_set_destroy(&mutations);
ovsdb_condition_destroy(&condition);
return error;
}
2009-11-04 15:11:44 -08:00
struct delete_row_cbdata {
size_t n_matches;
const struct ovsdb_table *table;
struct ovsdb_txn *txn;
};
static bool
delete_row_cb(const struct ovsdb_row *row, void *dr_)
{
struct delete_row_cbdata *dr = dr_;
dr->n_matches++;
ovsdb_txn_row_delete(dr->txn, row);
return true;
}
static struct ovsdb_error *
2009-11-04 15:11:44 -08:00
ovsdb_execute_delete(struct ovsdb_execution *x, struct ovsdb_parser *parser,
struct json *result)
{
struct ovsdb_table *table;
const struct json *where;
struct ovsdb_condition condition = OVSDB_CONDITION_INITIALIZER(&condition);
2009-11-04 15:11:44 -08:00
struct ovsdb_error *error;
where = ovsdb_parser_member(parser, "where", OP_ARRAY);
table = parse_table(x, parser, "table");
error = ovsdb_parser_get_error(parser);
if (!error) {
error = ovsdb_condition_from_json(table->schema, where, x->symtab,
&condition);
}
if (!error) {
struct delete_row_cbdata dr;
dr.n_matches = 0;
dr.table = table;
dr.txn = x->txn;
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
if (ovsdb_rbac_delete(x->db, table, &condition, x->role, x->id,
x->txn)) {
ovsdb_query(table, &condition, delete_row_cb, &dr, x->txn);
} else {
error = ovsdb_perm_error("RBAC rules for client \"%s\" role "
"\"%s\" prohibit row deletion from "
"table \"%s\".",
x->id, x->role, table->schema->name);
}
2009-11-04 15:11:44 -08:00
json_object_put(result, "count", json_integer_create(dr.n_matches));
}
ovsdb_condition_destroy(&condition);
return error;
}
struct wait_auxdata {
struct ovsdb_row_hash *actual;
struct ovsdb_row_hash *expected;
bool *equal;
};
static bool
ovsdb_execute_wait_query_cb(const struct ovsdb_row *row, void *aux_)
{
struct wait_auxdata *aux = aux_;
if (ovsdb_row_hash_contains(aux->expected, row)) {
ovsdb_row_hash_insert(aux->actual, row);
return true;
} else {
/* The query row isn't in the expected result set, so the actual and
* expected results sets definitely differ and we can short-circuit the
* rest of the query. */
*aux->equal = false;
return false;
}
}
static struct ovsdb_error *
ovsdb_execute_wait(struct ovsdb_execution *x, struct ovsdb_parser *parser,
struct json *result OVS_UNUSED)
2009-11-04 15:11:44 -08:00
{
struct ovsdb_table *table;
const struct json *timeout, *where, *columns_json, *until, *rows;
struct ovsdb_condition condition = OVSDB_CONDITION_INITIALIZER(&condition);
2009-11-04 15:11:44 -08:00
struct ovsdb_column_set columns = OVSDB_COLUMN_SET_INITIALIZER;
struct ovsdb_row_hash expected = OVSDB_ROW_HASH_INITIALIZER(expected);
struct ovsdb_row_hash actual = OVSDB_ROW_HASH_INITIALIZER(actual);
struct ovsdb_error *error;
struct wait_auxdata aux;
long long int timeout_msec = 0;
size_t i, n;
2009-11-04 15:11:44 -08:00
timeout = ovsdb_parser_member(parser, "timeout", OP_INTEGER | OP_OPTIONAL);
2009-11-04 15:11:44 -08:00
where = ovsdb_parser_member(parser, "where", OP_ARRAY);
columns_json = ovsdb_parser_member(parser, "columns",
OP_ARRAY | OP_OPTIONAL);
until = ovsdb_parser_member(parser, "until", OP_STRING);
rows = ovsdb_parser_member(parser, "rows", OP_ARRAY);
table = parse_table(x, parser, "table");
error = ovsdb_parser_get_error(parser);
if (!error) {
error = ovsdb_condition_from_json(table->schema, where, x->symtab,
&condition);
}
if (!error) {
error = ovsdb_column_set_from_json(columns_json, table->schema,
&columns);
2009-11-04 15:11:44 -08:00
}
if (!error) {
if (timeout) {
timeout_msec = json_integer(timeout);
2009-11-04 15:11:44 -08:00
if (timeout_msec < 0) {
error = ovsdb_syntax_error(timeout, NULL,
"timeout must be nonnegative");
} else if (timeout_msec < x->timeout_msec) {
x->timeout_msec = timeout_msec;
}
} else {
timeout_msec = LLONG_MAX;
}
}
if (!error) {
2009-11-04 15:11:44 -08:00
if (strcmp(json_string(until), "==")
&& strcmp(json_string(until), "!=")) {
error = ovsdb_syntax_error(until, NULL,
"\"until\" must be \"==\" or \"!=\"");
}
}
if (!error) {
/* Parse "rows" into 'expected'. */
ovsdb_row_hash_init(&expected, &columns);
n = json_array_size(rows);
for (i = 0; i < n; i++) {
2009-11-04 15:11:44 -08:00
struct ovsdb_row *row;
row = ovsdb_row_create(table);
error = ovsdb_row_from_json(row, json_array_at(rows, i), x->symtab,
NULL, false);
2009-11-04 15:11:44 -08:00
if (error) {
ovsdb_row_destroy(row);
2009-11-04 15:11:44 -08:00
break;
}
if (!ovsdb_row_hash_insert(&expected, row)) {
/* XXX Perhaps we should abort with an error or log a
* warning. */
ovsdb_row_destroy(row);
}
}
}
if (!error) {
/* Execute query. */
bool equal = true;
ovsdb_row_hash_init(&actual, &columns);
aux.actual = &actual;
aux.expected = &expected;
aux.equal = &equal;
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
ovsdb_query(table, &condition, ovsdb_execute_wait_query_cb, &aux,
x->txn);
2009-11-04 15:11:44 -08:00
if (equal) {
/* We know that every row in 'actual' is also in 'expected'. We
* also know that all of the rows in 'actual' are distinct and that
* all of the rows in 'expected' are distinct. Therefore, if
* 'actual' and 'expected' have the same number of rows, then they
* have the same content. */
size_t n_actual = ovsdb_row_hash_count(&actual);
size_t n_expected = ovsdb_row_hash_count(&expected);
equal = n_actual == n_expected;
}
if (!strcmp(json_string(until), "==") != equal) {
if (timeout && x->elapsed_msec >= timeout_msec) {
if (x->elapsed_msec) {
error = ovsdb_error("timed out",
"\"wait\" timed out after %lld ms",
x->elapsed_msec);
} else {
error = ovsdb_error("timed out",
"\"where\" clause test failed");
2009-11-04 15:11:44 -08:00
}
} else {
/* ovsdb_execute() will change this, if triggers really are
* supported. */
error = ovsdb_error("not supported", "triggers not supported");
}
}
}
ovsdb_row_hash_destroy(&expected, true);
ovsdb_row_hash_destroy(&actual, false);
ovsdb_column_set_destroy(&columns);
ovsdb_condition_destroy(&condition);
return error;
}
static struct ovsdb_error *
ovsdb_execute_comment(struct ovsdb_execution *x, struct ovsdb_parser *parser,
struct json *result OVS_UNUSED)
{
const struct json *comment;
comment = ovsdb_parser_member(parser, "comment", OP_STRING);
if (!comment) {
return NULL;
}
ovsdb_txn_add_comment(x->txn, json_string(comment));
return NULL;
}
static struct ovsdb_error *
ovsdb_execute_assert(struct ovsdb_execution *x, struct ovsdb_parser *parser,
struct json *result OVS_UNUSED)
{
const struct json *lock_name;
lock_name = ovsdb_parser_member(parser, "lock", OP_ID);
if (!lock_name) {
return NULL;
}
if (x->session) {
const struct ovsdb_lock_waiter *waiter;
waiter = ovsdb_session_get_lock_waiter(x->session,
json_string(lock_name));
if (waiter && ovsdb_lock_waiter_is_owner(waiter)) {
return NULL;
}
}
return ovsdb_error("not owner", "Asserted lock %s not held.",
json_string(lock_name));
}