Hi Han,
I had requests to move this to cli. This also allows a unified format if we add
parallelization to ovsdb or controller.
On 25 October 2021 04:05:39 BST, Han Zhou wrote:
>On Tue, Sep 21, 2021 at 8:48 AM wrote:
>>
>> From: Anton Ivanov
>>
>> libs: add config
From: Anton Ivanov
Weak may fail for reasons unrelated to the comparison (not
on x86, where these are practically equivalent).
Thus, it can and should be used only in cases where there will
be a repeat of the event which runs the code (in this case
semaphore post).
On non-x86 architectures
From: Anton Ivanov
1. Compute dp group hash only if there will be dp group processing.
2. Remove hmapx interim storage and related hmapx computation for
single dp flows and replace it with a pre-sized hmap.
Signed-off-by: Anton Ivanov
---
northd/northd.c | 50
From: Anton Ivanov
1. Compute dp group hash only if there will be dp group processing.
2. Remove hmapx interim storage and related hmapx computation for
single dp flows and replace it with a pre-sized hmap.
Signed-off-by: Anton Ivanov
---
northd/northd.c | 48
On 04/10/2021 16:58, Han Zhou wrote:
On Mon, Oct 4, 2021 at 2:31 AM Anton Ivanov mailto:anton.iva...@cambridgegreys.com>> wrote:
>
>
> On 03/10/2021 23:45, Han Zhou wrote:
> > The current implementation of parallel build in northd with dp-groups
> > enabled resu
On 04/10/2021 02:37, Han Zhou wrote:
It is not used, and seems not going to be needed, so remove it.
Signed-off-by: Han Zhou
---
lib/ovn-parallel-hmap.c | 1 -
lib/ovn-parallel-hmap.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/lib/ovn-parallel-hmap.c b/lib/ovn-parallel-hmap.c
On 04/10/2021 02:37, Han Zhou wrote:
Although not used currently, it is better to fix:
1. The type of the mask field should be the same as hmap->mask: size_t.
2. Calculating the index is better to use & instead of %.
Signed-off-by: Han Zhou
---
lib/ovn-parallel-hmap.h | 6 +++---
1 file
On 03/10/2021 23:45, Han Zhou wrote:
The current implementation of parallel build in northd with dp-groups
enabled results in bad performance when the below assumption is not
true:
* 3. Most RW ops are not flow adds, but changes to the
* od groups.
In fact most (if not all) of the ovn
On 03/10/2021 23:45, Han Zhou wrote:
When parallel build is used, od->group can be updated by threads outside
of the function do_ovn_lflow_add_pd (for lb related flow building). So
use the function ovn_dp_group_add_with_reference() to update it in
function do_ovn_lflow_add() when it is not a
On 03/10/2021 23:45, Han Zhou wrote:
Signed-off-by: Han Zhou
---
northd/northd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/northd/northd.c b/northd/northd.c
index cf2467fe1..027c5b170 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -4475,7 +4475,7 @@
On 01/10/2021 23:29, Han Zhou wrote:
The current implementation of parallel build in northd with dp-groups
enabled results in bad performance when the below assumption is not
true:
* 3. Most RW ops are not flow adds, but changes to the
* od groups.
Hi Han,
Have a look at the
On 01/10/2021 01:32, Han Zhou wrote:
On Thu, Sep 30, 2021 at 2:03 PM Anton Ivanov
<mailto:anton.iva...@cambridgegreys.com>> wrote:
On 30/09/2021 20:48, Han Zhou wrote:
On Thu, Sep 30, 2021 at 7:34 AM Anton Ivanov
mailto:anton.iva...@cambridgegreys.co
On 30/09/2021 20:48, Han Zhou wrote:
On Thu, Sep 30, 2021 at 7:34 AM Anton Ivanov
<mailto:anton.iva...@cambridgegreys.com>> wrote:
Summary of findings.
1. The numbers on the perf test do not align with heater which is
much closer to a realistic load. On some tests whe
Sep 30, 2021 at 12:08 AM Anton Ivanov mailto:anton.iva...@cambridgegreys.com>> wrote:
After quickly adding some more prints into the testsuite.
Test 1:
Without
1: ovn-northd basic scale test -- 200 Hypervisors, 200 Logical
Ports/Hypervisor -- ovn-northd -- d
be parallelized at present. Some of
it may be run in parallel if there were parallel macros in the OVS source, but
they are likely to give only marginal effect on performance - 1-2% at most.
Best Regards,
A.
On 30/09/2021 08:26, Han Zhou wrote:
On Thu, Sep 30, 2021 at 12:08 AM Anton Ivanov
an
On Wed, Sep 29, 2021 at 11:31 PM Anton Ivanov mailto:anton.iva...@cambridgegreys.com>> wrote:
On 30/09/2021 07:16, Anton Ivanov wrote:
Results on a Ryzen 5 3600 - 6 cores 12 threads
I will also have a look into the "maximum" measurement for multi-thread.
It doe
On 30/09/2021 07:16, Anton Ivanov wrote:
Results on a Ryzen 5 3600 - 6 cores 12 threads
I will also have a look into the "maximum" measurement for multi-thread.
It does not tie up with the drop in average across the board.
A.
Without
1: ovn-northd basic scale test -- 200 H
one slower is test 6 which I will look into.
The rest are > 5% faster.
A.
On 30/09/2021 00:56, Han Zhou wrote:
On Wed, Sep 15, 2021 at 5:45 AM <mailto:anton.iva...@cambridgegreys.com>> wrote:
>
> From: Anton Ivanov <mailto:anton.iva...@cambridgegreys.com>>
>
&g
I need to have a look.
I use the ovn-heater end-to-end test, that was showing a substantial
improvement.
What are you running this on?
A.
On 30/09/2021 00:56, Han Zhou wrote:
On Wed, Sep 15, 2021 at 5:45 AM <mailto:anton.iva...@cambridgegreys.com>> wrote:
>
> Fro
From: Anton Ivanov
No point to abuse CPU with sorting (in a worst case scenario -
up to million of rows in OVN) unless a human is reading the result.
The machine on the other side could not care less if it is
sorted or not.
Signed-off-by: Anton Ivanov
---
lib/json.c | 9 -
1 file
From: Anton Ivanov
There is no point to sort JSON objects when nobody is
observing them. Machines do not care if it is sorted or
not.
Signed-off-by: Anton Ivanov
---
lib/jsonrpc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/jsonrpc.c b/lib/jsonrpc.c
index
From: Anton Ivanov
1. Make pool size user defineable.
2. Expose pool destruction.
3. Make pools resizeable at runtime.
4. Split pool start and completion to allow background execution.
5. Add a simplified API for SAFE walking single hash.
Signed-off-by: Anton Ivanov
---
lib/ovn-parallel
From: Anton Ivanov
libs: add configuration support to parallel-hmap.[c,h]
northd: add support for configuring parallelization to northd
Signed-off-by: Anton Ivanov
---
lib/ovn-parallel-hmap.c | 185 ++--
lib/ovn-parallel-hmap.h | 63 +-
northd
:49 PM, Mark Michelson wrote:
On 9/17/21 1:38 PM, Ilya Maximets wrote:
On 9/15/21 14:43, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently in use
is not reliable. Disabling parallel
On 17/09/2021 18:23, Mark Michelson wrote:
Hi Anton,
For the series:
Acked-by: Mark Michelson
Thanks.
On 9/15/21 8:43 AM, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently
From: Anton Ivanov
1. Compute dp group hash only if there will be dp group processing.
2. Remove hmapx interim storage and related hmapx computation for
single dp flows and replace it with a pre-sized hmap.
Signed-off-by: Anton Ivanov
---
northd/ovn-northd.c | 55
On 15/09/2021 13:45, Anton Ivanov wrote:
I have dropped the split processing of lflows for now.
Sorry, pressed send to early by mistake.
V8 has the same code as the existing ovn for single thread and code derived
from the my split processing work for multi-thread.
It is tested
I have dropped the split processing of lflows for now.
On 10/09/2021 17:13, Ilya Maximets wrote:
On 9/10/21 4:19 PM, Anton Ivanov wrote:
On 10/09/2021 13:29, Ilya Maximets wrote:
On 9/10/21 2:23 PM, Anton Ivanov wrote:
On 10/09/2021 13:18, Anton Ivanov wrote:
On 10/09/2021 12:43, Ilya
From: Anton Ivanov
Restore parallel build with dp groups using rwlock instead
of per row locking as an underlying mechanism.
This provides improvement ~ 10% end-to-end on ovn-heater
under virutalization despite awakening some qemu gremlin
which makes qemu climb to silly CPU usage. The gain
From: Anton Ivanov
Parallel builds may result in suboptimal hash bucket sizing.
In the absense of dp-groups this does not matter as the hash
is purely storage and not used for lookups during the build.
Such a hash needs to be resized to a correct size at the end
of the build to ensure that any
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently in use
is not reliable. Disabling parallel processing if dp_groups
are enabled until the root cause is determined and fixed.
Signed-off-by: Anton Ivanov
---
northd/ovn
On 10/09/2021 16:37, Dumitru Ceara wrote:
On 9/10/21 2:18 PM, Anton Ivanov wrote:
On a side note, I ran some tests with this patch set applied and it drops
performance of non-parallel case by 20% on my laptop with databases from
the ovn-heater's 120 node density test.
I see, you mentioned 10
The culprit has been found and neutralized.
It is now marginally faster (~ 0.5%) than master.
I will do full retests and scale tests for all combinations including parallel
and if it tests out OK post v8 tomorrow.
A.
On 10/09/2021 17:13, Ilya Maximets wrote:
On 9/10/21 4:19 PM, Anton Ivanov
On 10/09/2021 17:13, Ilya Maximets wrote:
On 9/10/21 4:19 PM, Anton Ivanov wrote:
On 10/09/2021 13:29, Ilya Maximets wrote:
On 9/10/21 2:23 PM, Anton Ivanov wrote:
On 10/09/2021 13:18, Anton Ivanov wrote:
On 10/09/2021 12:43, Ilya Maximets wrote:
On 9/9/21 11:02 PM, Mark Michelson wrote
Thanks, I will update to the newer version.
A.
On 10/09/2021 16:37, Dumitru Ceara wrote:
On 9/10/21 2:18 PM, Anton Ivanov wrote:
On a side note, I ran some tests with this patch set applied and it drops
performance of non-parallel case by 20% on my laptop with databases from
the ovn-heater's
On 10/09/2021 13:29, Ilya Maximets wrote:
On 9/10/21 2:23 PM, Anton Ivanov wrote:
On 10/09/2021 13:18, Anton Ivanov wrote:
On 10/09/2021 12:43, Ilya Maximets wrote:
On 9/9/21 11:02 PM, Mark Michelson wrote:
Hi Anton,
On a high level, this change results in some parts of the parallelized
From: Anton Ivanov
Remove full hash walks to form lflow dp_groups and add them
to the overall parallelizeable lflow build.
Make processing of "with dp groups" and "without" in
build_lflows independent to allow these to run in parallel
after the updates to the parallel
From: Anton Ivanov
Restore parallel build with dp groups using rwlock instead
of per row locking as an underlying mechanism.
This provides improvement ~ 10% end-to-end on ovn-heater
under virutalization despite awakening some qemu gremlin
which makes qemu climb to silly CPU usage. The gain
From: Anton Ivanov
Parallel builds may result in suboptimal hash bucket sizing.
In the absense of dp-groups this does not matter as the hash
is purely storage and not used for lookups during the build.
Such a hash needs to be resized to a correct size at the end
of the build to ensure that any
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently in use
is not reliable. Disabling parallel processing if dp_groups
are enabled until the root cause is determined and fixed.
Signed-off-by: Anton Ivanov
---
northd/ovn
On 10/09/2021 13:49, Anton Ivanov wrote:
On 10/09/2021 13:34, Anton Ivanov wrote:
On 10/09/2021 13:29, Ilya Maximets wrote:
On 9/10/21 2:23 PM, Anton Ivanov wrote:
On 10/09/2021 13:18, Anton Ivanov wrote:
On 10/09/2021 12:43, Ilya Maximets wrote:
On 9/9/21 11:02 PM, Mark Michelson wrote
On 10/09/2021 13:34, Anton Ivanov wrote:
On 10/09/2021 13:29, Ilya Maximets wrote:
On 9/10/21 2:23 PM, Anton Ivanov wrote:
On 10/09/2021 13:18, Anton Ivanov wrote:
On 10/09/2021 12:43, Ilya Maximets wrote:
On 9/9/21 11:02 PM, Mark Michelson wrote:
Hi Anton,
On a high level, this change
On 10/09/2021 13:29, Ilya Maximets wrote:
On 9/10/21 2:23 PM, Anton Ivanov wrote:
On 10/09/2021 13:18, Anton Ivanov wrote:
On 10/09/2021 12:43, Ilya Maximets wrote:
On 9/9/21 11:02 PM, Mark Michelson wrote:
Hi Anton,
On a high level, this change results in some parts of the parallelized
On 10/09/2021 13:18, Anton Ivanov wrote:
On 10/09/2021 12:43, Ilya Maximets wrote:
On 9/9/21 11:02 PM, Mark Michelson wrote:
Hi Anton,
On a high level, this change results in some parts of the parallelized hashmap
being unused. Should we keep the hashrow_locks structure and its APIs
.
On 9/2/21 9:27 AM, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
Restore parallel build with dp groups using rwlock instead
of per row locking as an underlying mechanism.
This provides improvement ~ 10% end-to-end on ovn-heater
under virutalization despite awakening some qemu gremlin
w for more comments.
On 9/2/21 9:27 AM, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
Restore parallel build with dp groups using rwlock instead
of per row locking as an underlying mechanism.
This provides improvement ~ 10% end-to-end on ovn-heater
under virutalization despite awakening
discussion.
On 9/2/21 9:27 AM, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
Restore parallel build with dp groups using rwlock instead
of per row locking as an underlying mechanism.
This provides improvement ~ 10% end-to-end on ovn-heater
under virutalization despite awakening some
processing. While it is no longer used in lflow generation, it may stay
as it may come handy elsewhere.
Some renaming is probably in order - the names are too lflow specific.
A.
See below for more comments.
On 9/2/21 9:27 AM, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
Restore
and their parallelization.
A.
On 02/09/2021 19:30, Numan Siddique wrote:
On Mon, Aug 16, 2021 at 1:31 PM wrote:
From: Anton Ivanov
1. Make pool size user defineable.
2. Expose pool destruction.
3. Make pools resizeable at runtime.
Signed-off-by: Anton Ivanov
Hi Anton,
Thanks for the patch
From: Anton Ivanov
Signed-off-by: Anton Ivanov
---
lib/ovn-parallel-hmap.c | 209 ++--
lib/ovn-parallel-hmap.h | 63 +++-
northd/ovn-northd.c | 26 ++---
tests/ovn-macros.at | 16 ++-
4 files changed, 283 insertions(+), 31 deletions
From: Anton Ivanov
1. Make pool size user defineable.
2. Expose pool destruction.
3. Make pools resizeable at runtime.
Signed-off-by: Anton Ivanov
---
lib/ovn-parallel-hmap.c | 202 ++--
lib/ovn-parallel-hmap.h | 23 -
northd/ovn-northd.c | 58
From: Anton Ivanov
1. Make pool size user defineable.
2. Expose pool destruction.
3. Make pools resizeable at runtime.
Signed-off-by: Anton Ivanov
---
lib/ovn-parallel-hmap.c | 202 ++--
lib/ovn-parallel-hmap.h | 23 -
northd/ovn-northd.c | 58
On 02/09/2021 21:20, Numan Siddique wrote:
On Thu, Sep 2, 2021 at 3:20 PM Anton Ivanov
wrote:
On 02/09/2021 19:30, Numan Siddique wrote:
On Mon, Aug 16, 2021 at 1:31 PM wrote:
From: Anton Ivanov
1. Make pool size user defineable.
2. Expose pool destruction.
3. Make pools resizeable
On 03/09/2021 08:56, Dumitru Ceara wrote:
On 9/2/21 10:20 PM, Numan Siddique wrote:\
[...]
Can we have some suggestions for option names please?
How about num_parallel_workers ?
So user/CMS has to set 2 options (unfortunately)
use_parallel_build=true
num_parallel_workers=6
Or we can
On 02/09/2021 19:30, Numan Siddique wrote:
On Mon, Aug 16, 2021 at 1:31 PM wrote:
From: Anton Ivanov
1. Make pool size user defineable.
2. Expose pool destruction.
3. Make pools resizeable at runtime.
Signed-off-by: Anton Ivanov
Hi Anton,
Thanks for the patch. If I understand correctly
From: Anton Ivanov
Restore parallel build with dp groups using rwlock instead
of per row locking as an underlying mechanism.
This provides improvement ~ 10% end-to-end on ovn-heater
under virutalization despite awakening some qemu gremlin
which makes qemu climb to silly CPU usage. The gain
From: Anton Ivanov
Remove full hash walks to form lflow dp_groups and add them
to the overall parallelizeable lflow build.
Make processing of "with dp groups" and "without" in
build_lflows independent to allow these to run in parallel
after the updates to the parallel
From: Anton Ivanov
Parallel builds may result in suboptimal hash bucket sizing.
In the absense of dp-groups this does not matter as the hash
is purely storage and not used for lookups during the build.
Such a hash needs to be resized to a correct size at the end
of the build to ensure that any
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently in use
is not reliable. Disabling parallel processing if dp_groups
are enabled until the root cause is determined and fixed.
Signed-off-by: Anton Ivanov
---
northd/ovn
From: Anton Ivanov
Restore parallel build with dp groups using rwlock instead
of per row locking as an underlying mechanism.
This provides improvement ~ 10% end-to-end on ovn-heater
under virutalization despite awakening some qemu gremlin
which makes qemu climb to silly CPU usage. The gain
From: Anton Ivanov
Remove full hash walks to form lflow dp_groups and add them
to the overall parallelizeable lflow build.
Make processing of "with dp groups" and "without" in
build_lflows independent to allow these to run in parallel
after the updates to the parallel
From: Anton Ivanov
Parallel builds may result in suboptimal hash bucket sizing.
In the absense of dp-groups this does not matter as the hash
is purely storage and not used for lookups during the build.
Such a hash needs to be resized to a correct size at the end
of the build to ensure that any
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently in use
is not reliable. Disabling parallel processing if dp_groups
are enabled until the root cause is determined and fixed.
Signed-off-by: Anton Ivanov
---
northd/ovn
From: Anton Ivanov
Restore parallel build with dp groups using rwlock instead
of per row locking as an underlying mechanism.
This provides improvement ~ 10% end-to-end on ovn-heater
under virutalization despite awakening some qemu gremlin
which makes qemu climb to silly CPU usage. The gain
From: Anton Ivanov
Remove full hash walks to form lflow dp_groups and add them
to the overall parallelizeable lflow build.
Make processing of "with dp groups" and "without" in
build_lflows independent to allow these to run in parallel
after the updates to the parallel
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently in use
is not reliable. Disabling parallel processing if dp_groups
are enabled until the root cause is determined and fixed.
Signed-off-by: Anton Ivanov
---
northd/ovn
From: Anton Ivanov
Parallel builds may result in suboptimal hash bucket sizing.
In the absense of dp-groups this does not matter as the hash
is purely storage and not used for lookups during the build.
Such a hash needs to be resized to a correct size at the end
of the build to ensure that any
There are options for that.
Debug mode should never be a default.
On 30 August 2021 12:29:16 BST, Ilya Maximets wrote:
>On 8/26/21 7:31 AM, Anton Ivanov wrote:
>> On 25/08/2021 22:12, Ilya Maximets wrote:
>>> On 8/25/21 5:17 PM, anton.iva...@cambridgegreys.com wrote:
>&
From: Anton Ivanov
Restore parallel build with dp groups using rwlock instead
of per row locking as an underlying mechanism.
This provides improvement ~ 10% end-to-end on ovn-heater
under virutalization despite awakening some qemu gremlin
which makes qemu climb to silly CPU usage. The gain
From: Anton Ivanov
Remove full hash walks to form lflow dp_groups and add them
to the overall parallelizeable lflow build.
Make processing of "with dp groups" and "without" in
build_lflows independent to allow these to run in parallel
after the updates to the parallel
From: Anton Ivanov
Parallel builds may result in suboptimal hash bucket sizing.
In the absense of dp-groups this does not matter as the hash
is purely storage and not used for lookups during the build.
Such a hash needs to be resized to a correct size at the end
of the build to ensure that any
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently in use
is not reliable. Disabling parallel processing if dp_groups
are enabled until the root cause is determined and fixed.
Signed-off-by: Anton Ivanov
---
northd/ovn
From: Anton Ivanov
Remove full hash walks to form lflow dp_groups and add them
to the overall parallelizeable lflow build.
Make processing of "with dp groups" and "without" in
build_lflows independent to allow these to run in parallel
after the updates to the parallel
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently in use
is not reliable. Disabling parallel processing if dp_groups
are enabled until the root cause is determined and fixed.
Signed-off-by: Anton Ivanov
---
northd/ovn
From: Anton Ivanov
Parallel builds may result in suboptimal hash bucket sizing.
In the absense of dp-groups this does not matter as the hash
is purely storage and not used for lookups during the build.
Such a hash needs to be resized to a correct size at the end
of the build to ensure that any
From: Anton Ivanov
Remove full hash walks to form lflow dp_groups and add them
to the overall parallelizeable lflow build.
Make processing of "with dp groups" and "without" in
build_lflows independent to allow these to run in parallel
after the updates to the parallel
From: Anton Ivanov
Parallel builds may result in suboptimal hash bucket sizing.
In the absense of dp-groups this does not matter as the hash
is purely storage and not used for lookups during the build.
Such a hash needs to be resized to a correct size at the end
of the build to ensure that any
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently in use
is not reliable. Disabling parallel processing if dp_groups
are enabled until the root cause is determined and fixed.
Signed-off-by: Anton Ivanov
---
northd/ovn
From: Anton Ivanov
Remove full hash walks to form lflow dp_groups and add them
to the overall parallelizeable lflow build.
Make processing of "with dp groups" and "without" in
build_lflows independent to allow these to run in parallel
after the updates to the parallel
From: Anton Ivanov
Parallel builds may result in suboptimal hash bucket sizing.
In the absense of dp-groups this does not matter as the hash
is purely storage and not used for lookups during the build.
Such a hash needs to be resized to a correct size at the end
of the build to ensure that any
From: Anton Ivanov
Work on improving processing with dp_groups enabled has
discovered that the locking mechanism presently in use
is not reliable. Disabling parallel processing if dp_groups
are enabled until the root cause is determined and fixed.
Signed-off-by: Anton Ivanov
---
northd/ovn
On 25/08/2021 22:12, Ilya Maximets wrote:
On 8/25/21 5:17 PM, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
A JSON object sort order is by definition arbitrary. OVS
parser(s) do not care about object order - the result is
loaded into a SHASH losing any order on the wire.
Having
From: Anton Ivanov
A JSON object sort order is by definition arbitrary. OVS
parser(s) do not care about object order - the result is
loaded into a SHASH losing any order on the wire.
Having the objects sorted is a performance penalty, especially
for large objects like f.e. lflow state
On 25/08/2021 08:35, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
When running with dp_groups and parallelization enabled we have
a possible worse case scenario where northd connects for the
first time to a pre-populated database.
If we do not size the hash to a sufficiently
On 25/08/2021 13:08, Ilya Maximets wrote:
On 8/20/21 11:16 AM, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
Set a soft time limit of "raft election timer"/2 on ovsdb
processing.
This improves behaviour in large heavily loaded clusters.
While it cannot fully eliminat
From: Anton Ivanov
Parallel builds may result in suboptimal hash bucket sizing.
In the absense of dp-groups this does not matter as the hash
is purely storage and not used for lookups during the build.
Such a hash needs to be resized to a correct size at the end
of the build to ensure that any
From: Anton Ivanov
When running with dp_groups and parallelization enabled we have
a possible worse case scenario where northd connects for the
first time to a pre-populated database.
If we do not size the hash to a sufficiently big size to
accommodate for this, we end up with severe lock
On 24/08/2021 22:49, Ilya Maximets wrote:
On 8/24/21 10:07 PM, Anton Ivanov wrote:
On 23/08/2021 22:36, Ilya Maximets wrote:
On 8/23/21 10:37 PM, Anton Ivanov wrote:
On 23/08/2021 21:26, Ilya Maximets wrote:
On 8/23/21 10:20 PM, Anton Ivanov wrote:
Should not be the case.
The map is pre
On 23/08/2021 22:36, Ilya Maximets wrote:
On 8/23/21 10:37 PM, Anton Ivanov wrote:
On 23/08/2021 21:26, Ilya Maximets wrote:
On 8/23/21 10:20 PM, Anton Ivanov wrote:
Should not be the case.
The map is pre-sized for the size from the previous iterations.
Line 12861 in my tree which
On 24/08/2021 19:16, Ilya Maximets wrote:
On 8/24/21 7:48 PM, Numan Siddique wrote:
On Tue, Aug 24, 2021 at 1:24 PM Anton Ivanov
wrote:
On 24/08/2021 17:35, Ilya Maximets wrote:
On 8/24/21 6:25 PM, Numan Siddique wrote:
On Tue, Aug 24, 2021 at 7:56 AM Anton Ivanov
wrote:
On 24/08/2021 12
On 24/08/2021 18:48, Numan Siddique wrote:
On Tue, Aug 24, 2021 at 1:24 PM Anton Ivanov
wrote:
On 24/08/2021 17:35, Ilya Maximets wrote:
On 8/24/21 6:25 PM, Numan Siddique wrote:
On Tue, Aug 24, 2021 at 7:56 AM Anton Ivanov
wrote:
On 24/08/2021 12:46, Ilya Maximets wrote:
On 8/24/21 1:18
On 24/08/2021 17:35, Ilya Maximets wrote:
On 8/24/21 6:25 PM, Numan Siddique wrote:
On Tue, Aug 24, 2021 at 7:56 AM Anton Ivanov
wrote:
On 24/08/2021 12:46, Ilya Maximets wrote:
On 8/24/21 1:18 PM, Anton Ivanov wrote:
On 24/08/2021 12:05, Ilya Maximets wrote:
On 8/24/21 7:36 AM, Anton
On 24/08/2021 17:25, Numan Siddique wrote:
On Tue, Aug 24, 2021 at 7:56 AM Anton Ivanov
wrote:
On 24/08/2021 12:46, Ilya Maximets wrote:
On 8/24/21 1:18 PM, Anton Ivanov wrote:
On 24/08/2021 12:05, Ilya Maximets wrote:
On 8/24/21 7:36 AM, Anton Ivanov wrote:
On 23/08/2021 22:36, Ilya
On 24/08/2021 12:46, Ilya Maximets wrote:
On 8/24/21 1:18 PM, Anton Ivanov wrote:
On 24/08/2021 12:05, Ilya Maximets wrote:
On 8/24/21 7:36 AM, Anton Ivanov wrote:
On 23/08/2021 22:36, Ilya Maximets wrote:
On 8/23/21 10:37 PM, Anton Ivanov wrote:
On 23/08/2021 21:26, Ilya Maximets wrote
On 24/08/2021 12:05, Ilya Maximets wrote:
On 8/24/21 7:36 AM, Anton Ivanov wrote:
On 23/08/2021 22:36, Ilya Maximets wrote:
On 8/23/21 10:37 PM, Anton Ivanov wrote:
On 23/08/2021 21:26, Ilya Maximets wrote:
On 8/23/21 10:20 PM, Anton Ivanov wrote:
Should not be the case.
The map is pre
On 23/08/2021 22:36, Ilya Maximets wrote:
On 8/23/21 10:37 PM, Anton Ivanov wrote:
On 23/08/2021 21:26, Ilya Maximets wrote:
On 8/23/21 10:20 PM, Anton Ivanov wrote:
Should not be the case.
The map is pre-sized for the size from the previous iterations.
Line 12861 in my tree which
On 23/08/2021 21:26, Ilya Maximets wrote:
On 8/23/21 10:20 PM, Anton Ivanov wrote:
Should not be the case.
The map is pre-sized for the size from the previous iterations.
Line 12861 in my tree which is probably a few commits out of date:
fast_hmap_size_for(, max_seen_lflow_size
run.
We can't expand the hash map in case of parallel build, so this
should be fixed separately.
CC: Anton Ivanov
Fixes: 74daa0607c7f ("ovn-northd: Introduce parallel lflow build")
Signed-off-by: Ilya Maximets
---
northd/ovn-northd.c | 6 +-
1 file changed, 5 insertions(+), 1 dele
From: Anton Ivanov
Set a soft time limit of "raft election timer"/2 on ovsdb
processing.
This improves behaviour in large heavily loaded clusters.
While it cannot fully eliminate spurious raft elections
under heavy load, it significantly decreases their number.
Processing is (to
From: Anton Ivanov
This allows to leverage the openssl implementation which can use
hardware crypto on supported platforms.
UUID generation speed is improved by ~ 12% on an AMD Ryzen with
support for AES instructions.
Signed-off-by: Anton Ivanov
---
lib/aes128.c| 79
1 - 100 of 497 matches
Mail list logo
