On Fri, Jan 21, 2022 at 1:03 PM Ilya Maximets <i.maxim...@ovn.org> wrote:
>
> On 1/7/22 21:41, Mike Pattrick wrote:
> >> diff --git a/ovsdb/relay.c b/ovsdb/relay.c
> >> index ef0e44d34..2df393403 100644
> >> --- a/ovsdb/relay.c
> >> +++ b/ovsdb/relay.c
> >> @@ -222,7 +222,8 @@ ovsdb_relay_process_row_update(struct ovsdb_table
> >> *table,
> >>
> >> static struct ovsdb_error *
> >> ovsdb_relay_parse_update__(struct ovsdb *db,
> >> - const struct ovsdb_cs_db_update *du)
> >> + const struct ovsdb_cs_db_update *du,
> >> + const struct uuid *last_id)
> >> {
> >> struct ovsdb_error *error = NULL;
> >> struct ovsdb_txn *txn;
> >> @@ -254,8 +255,17 @@ exit:
> >> ovsdb_txn_abort(txn);
> >> return error;
> >> } else {
> >> - /* Commit transaction. */
> >> - error = ovsdb_txn_propose_commit_block(txn, false);
> >> + if (uuid_is_zero(last_id)) {
> >> + /* The relay source doesn't support unique transaction ids,
> >> + * disabling transaction history for relay. */
> >> + ovsdb_txn_history_destroy(db);
> >> + ovsdb_txn_history_init(db, false);
> >
> > Nit: In the case that the relay doesn't support unique transaction ids
> > wouldn't this cause us to have to call destroy/init on every update,
> > even if it were already turned off?
>
> Yes, it will. But that should not be a big problem here, because
> ovsdb_txn_history_destroy() is just one check in that case, and
> init should not be heavy either. It's only ~5 memory writes and
> that should be negligible in compare with the actual processing of
> the received database update.
I think you're right that this shouldn't really impact performance.
Acked-by: Mike Pattrick <m...@redhat.com>
>
> We could add a separate API call like this:
>
> bool
> ovsdb_need_txn_history(struct ovsdb *db)
> {
> return db->need_txn_history;
> }
>
> and check, but it's kind of seems unnecessary for this use case.
> (I would like to not use db->need_txn_history directly here, even
> though we technically have access to it.)
>
> What do you think?
>
> Best regards, Ilya Maximets.
>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
