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.

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

Reply via email to