Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

The FDP team is no longer accepting new bugs in Bugzilla. Please report your issues under FDP project in Jira. Thanks.

Bug 2006845

Summary:	[RFE] ovsdb-server: Consolidate ovsdb_atom strings and json_string objects
Product:	Red Hat Enterprise Linux Fast Datapath	Reporter:	Ilya Maximets <i.maximets>
Component:	openvswitch2.17	Assignee:	Ilya Maximets <i.maximets>
Status:	CLOSED ERRATA	QA Contact:	Jean-Tsung Hsiao <jhsiao>
Severity:	high	Docs Contact:
Priority:	high
Version:	RHEL 8.0	CC:	ctrautma, jhsiao, ovs-qe, ralongi, tredaelli
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openvswitch2.17-2.17.0-4.el9fdp	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	2006839	Environment:
Last Closed:	2022-05-27 18:05:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2006839
Bug Blocks:

Description Ilya Maximets 2021-09-22 14:10:00 UTC

+++ This bug was initially created as a clone of Bug #2006839 +++

ovsdb-server spends a lot of time cloning atoms for various reasons,
e.g. to create a diff of two rows or to clone a row to the transaction.
All atoms, except for strings, contains a simple value that could be
copied in efficient way, but duplicating strings every time has a big
performance impact.

Preliminary tests with introduction of a  a new reference-counted structure
'ovsdb_atom_string' that allows to not copy strings every time, but just
increase a reference counter, shows 2x performance improvement for standalone
databases in terms of a number of transactions per second it can execute,
and 3x for clustered databases (these are copying atoms more frequently
due to transaction history support).

Initial implementation:
https://github.com/igsilya/ovs/commit/5756700c68cccd6e5bbe1ce86291e0a255e0669a

========================================

Based on the implementation of BZ 2006839, it should be possible to
consolidate 'json_string' and 'ovsdb_datum_string' structures, so they
can be used interchangeably.  This will allow to convert ovsdb_datum
objects to json objects and vice versa without duplicating strings,
but only increasing reference counters.  This should give noticeable
performance improvement for transaction throughput and, more importantly,
speed up database compactions, since all the strings in the database
will not be copied and freed later anymore.

Comment 1 Ilya Maximets 2021-10-25 13:48:34 UTC

Some initial implementation:
  https://github.com/igsilya/ovs/commit/2153bcc7a2c28d8cbbd2194665af71880308532d

Comment 2 Ilya Maximets 2021-11-22 00:17:46 UTC

Patches posted for review:
  https://patchwork.ozlabs.org/project/openvswitch/list/?series=273152&state=*

Comment 5 Jean-Tsung Hsiao 2022-05-18 15:26:57 UTC

Hi Ilya,
What test or tests I need to run to verify this RFE? Can you share your testing scripts.
Thanks!
Jean

Comment 6 Ilya Maximets 2022-05-18 17:37:01 UTC

(In reply to Jean-Tsung Hsiao from comment #5)
> Hi Ilya,
> What test or tests I need to run to verify this RFE? Can you share your
> testing scripts.

Hi, Jean.
As we discussed on irc, only regression testing is needed here. No special
checks required, since it's mostly an internal code re-work.

Comment 7 Jean-Tsung Hsiao 2022-05-19 13:42:08 UTC

During FDP 22.D testing our team has been testing openvswitch2.17-2.17.0-15.el9fdp heavily, and not seen any regression. On that I want to set the status to VERIFIED.

Comment 9 errata-xmlrpc 2022-05-27 18:05:34 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (openvswitch2.17), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:4792