Bleep bloop. Greetings Ben Pfaff, I am a robot and I have tried out your patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Line is 80 characters long (recommended limit is 79)
#148 FILE: lib/ovsdb-cs.c:159:
Bleep bloop. Greetings Ben Pfaff, I am a robot and I have tried out your patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Line is 82 characters long (recommended limit is 79)
#38 FILE: lib/ovsdb-cs.c:1:
/*
Bleep bloop. Greetings Ben Pfaff, I am a robot and I have tried out your patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Line is 80 characters long (recommended limit is 79)
#118 FILE: lib/reconnect.c:568:
Signed-off-by: Ben Pfaff
---
lib/ovsdb-idl.c | 8
1 file changed, 8 insertions(+)
diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
index 02a49b32454b..c6b6075d51e3 100644
--- a/lib/ovsdb-idl.c
+++ b/lib/ovsdb-idl.c
@@ -617,6 +617,14 @@ ovsdb_idl_destroy(struct ovsdb_idl *idl)
}
}
This new module has a single direct user now. In the future, it
will also be used by OVN.
Signed-off-by: Ben Pfaff
---
lib/automake.mk | 2 +
lib/ovsdb-cs.c | 326 +++
lib/ovsdb-cs.h | 70
lib/ovsdb-idl.c | 442
Signed-off-by: Ben Pfaff
---
lib/ovsdb-idl.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/ovsdb-idl.h b/lib/ovsdb-idl.h
index a1a577664e8e..789337df9f33 100644
--- a/lib/ovsdb-idl.h
+++ b/lib/ovsdb-idl.h
@@ -76,7 +76,6 @@ void ovsdb_idl_set_lock(struct ovsdb_idl *, const char
Until now, "test-ovsdb idl" has printed the steps that it goes through
to stdout. This commit also makes it log the same information. This
makes it easier to match up the steps with the rest of the log (in
particular with the jsonrpc logging).
Signed-off-by: Ben Pfaff
---
tests/test-ovsdb.c |
Adding parameter names makes these prototypes clearer.
Signed-off-by: Ben Pfaff
---
lib/ovsdb-idl.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/ovsdb-idl.h b/lib/ovsdb-idl.h
index 789337df9f33..05bb48d66c3f 100644
--- a/lib/ovsdb-idl.h
+++ b/lib/ovsdb-idl.h
@@
When there's no open session, we still have to free the messages that
we make but cannot send.
I'm not confident that these fix actual bugs, because it seems possible
that these code paths can only be hit when the session is nonnull.
Signed-off-by: Ben Pfaff
---
lib/ovsdb-idl.c | 10 --
ovsdb_idl_db_parse_monitor_reply() clears the IDL and parses the
received data. There's no need to do it again afterward.
Signed-off-by: Ben Pfaff
Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered
databases.")
---
lib/ovsdb-idl.c | 3 ---
1 file changed, 3 deletions(-)
Open vSwitch has a few different jsonrpc-based protocols that depend on
jsonrpc_session to make sure that the connection is up and working.
In turn, jsonrpc_session uses the "reconnect" state machine to send
probes if nothing is received. This works fine in normal circumstances.
In unusual
This series breaks the IDL into two layers: the IDL proper, whose
interface to its client is unchanged, and a low-level library called
the OVSDB "client synchronization" (CS) library. There are two
reasons for this change. First, the IDL is big and complicated and
I think that this change
On Wed, Dec 16, 2020 at 1:24 AM Ilya Maximets wrote:
>
> On 12/16/20 12:41 AM, Yi-Hung Wei wrote:
> > On userspace datapath, geneve option flag FLOW_TNL_F_UDPIF should only
> > be set when the geneve option is available. However, currently, we always
> > set FLOW_TNL_F_UDPIF in the metadata
Bleep bloop. Greetings Kevin Traynor, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Unexpected sign-offs from developers who are not authors or co-authors
or
On 12/17/20 7:14 PM, Ilya Maximets wrote:
> It is important to have memory reports in logs to track the state
> of OVN daemons. With this change we will see the dynamic of the
> memory consumption.
>
> We have no any specific information to report yet, but we have to
> call memory_report() to
On Thu, Dec 17, 2020 at 11:39 PM Mark Michelson wrote:
>
> Signed-off-by: Mark Michelson
>From the previous release patches, I have not seen a patch to master
branch to set the date.
But I have nothing against it.
Acked-by: Numan Siddique for the entire 3-patch series.
Thanks
Numan
> ---
On 12/17/20 6:22 PM, Ilya Maximets wrote:
> Fixes: 4e92542cefb7 ("ovsdb-tool: Make "show-log" convert raw JSON to
> easier-to-read syntax.")
> Signed-off-by: Ilya Maximets
> ---
Looks good to me, thanks!
Acked-by: Dumitru Ceara
___
dev mailing
From: Christophe Fontaine
Two important parts of how auto load balance operates is how
loaded a core needs to be and how much improvement is estimated
before an auto load balance can trigger.
Previously they were hardcoded to 95% loaded and 25% variance
improvement.
These default values may
Signed-off-by: Kevin Traynor
---
AUTHORS.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/AUTHORS.rst b/AUTHORS.rst
index 7282ca607..75019c13d 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -89,4 +89,5 @@ Carlo Andreottic.andreo...@m3s.it
Casey Barker
Previously if auto load balance was disabled, updates to parameters
did not get logged.
Add logs so that if there are any changes to the parameters, the change
is shown as well as the current enabled/disabled state of auto load balance.
Also, show the parameters when auto load balance is changed
v4:
- Changed naming of params
- Updated default #defines names
- Used atomic for param accessed in the pmd thread
- Revert to default if param range is exceeded
- Only set params if they are changed
- Add logging for params when they are changed
- Add log for auto load balance enabled/disabled
On 12/11/20 9:54 PM, Ilya Maximets wrote:
> Currently, ovsdb-server stores complete value for the column in a database
> file and in a raft log in case this column changed. This means that
> transaction that adds, for example, one new acl to a port group creates
> a log entry with all UUIDs of
Bleep bloop. Greetings Mark Michelson, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
git-am:
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed
On Thu, Dec 17, 2020 at 08:54:56AM -0800, Girish Moodalbail wrote:
> Hello all,
>
> Say, ovn-nbctl is started in daemon mode with options set for certs, and
> those certs do not exist on the file system. For example, in the following
> invocation assume that `/ovn-cert` folder is empty
>
>
On 12/17/20 7:43 PM, Ben Pfaff wrote:
> On Fri, Dec 11, 2020 at 09:54:47PM +0100, Ilya Maximets wrote:
>> Currently, ovsdb-server stores complete value for the column in a database
>> file and in a raft log in case this column changed. This means that
>> transaction that adds, for example, one
Here is the IRC log for the OVN meeting for 17 December, 2020
http://eavesdrop.openstack.org/meetings//ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-12-17-18.15.log.html
If you are interested in attending this meeting, it happens every
Thursday in the
On Fri, Dec 11, 2020 at 09:54:47PM +0100, Ilya Maximets wrote:
> Currently, ovsdb-server stores complete value for the column in a database
> file and in a raft log in case this column changed. This means that
> transaction that adds, for example, one new acl to a port group creates
> a log entry
On 12/17/20 6:05 PM, Ilya Maximets wrote:
> It is important to have memory reports in logs to track the state
> of OVN daemons. With this change we will see the dynamic of the
> memory consumption.
>
> We have no any specific information to report yet, but we have to
> call memory_report() to
It is important to have memory reports in logs to track the state
of OVN daemons. With this change we will see the dynamic of the
memory consumption.
We have no any specific information to report yet, but we have to
call memory_report() to reply to all the incoming 'memory/show'
requests.
Not
On Thu, Dec 17, 2020 at 06:20:05PM +0100, Ilya Maximets wrote:
> AddressSanitizer reports this as a leak.
> Let's just free the memory before exiting to avoid the noise.
>
> 'stream_close()' doesn't update the pointer, so this will not
> change the return value.
>
> Signed-off-by: Ilya Maximets
Signed-off-by: Mark Michelson
---
NEWS | 2 +-
debian/changelog | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index 2800de2f3..f71ec329c 100644
--- a/NEWS
+++ b/NEWS
@@ -1,4 +1,4 @@
-OVN v20.12.0 - xx xxx
+OVN v20.12.0 - 18 Dec 2020
Signed-off-by: Mark Michelson
---
NEWS | 2 +-
debian/changelog | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/NEWS b/NEWS
index f0ac94b8e..ce0781cbc 100644
--- a/NEWS
+++ b/NEWS
@@ -2,7 +2,7 @@ Post-v20.12.0
-
- Support ECMP
Signed-off-by: Mark Michelson
---
NEWS | 3 +++
configure.ac | 2 +-
debian/changelog | 6 ++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index f71ec329c..0d3f20cac 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+OVN v20.12.1 - xx xxx
On Thu, Dec 17, 2020 at 01:00:56PM +0100, Ilya Maximets wrote:
> On 11/23/20 3:12 PM, Ilya Maximets wrote:
> > Too big userdata could overflow netlink message leading to out-of-bound
> > memory accesses or assertion while formatting nested actions.
> >
> > Fix that by checking the saize and
On 12/17/20 6:24 PM, Gregory Rose wrote:
>
>
> On 12/17/2020 3:55 AM, Ilya Maximets wrote:
>> On 12/16/20 9:37 PM, Flavio Leitner wrote:
>>> On Sun, Nov 29, 2020 at 02:30:29AM +0100, Ilya Maximets wrote:
On 11/12/20 6:04 PM, Gregory Rose wrote:
>
>
> On 11/12/2020 5:10 AM, Mark
On 12/17/2020 3:55 AM, Ilya Maximets wrote:
On 12/16/20 9:37 PM, Flavio Leitner wrote:
On Sun, Nov 29, 2020 at 02:30:29AM +0100, Ilya Maximets wrote:
On 11/12/20 6:04 PM, Gregory Rose wrote:
On 11/12/2020 5:10 AM, Mark Gray wrote:
On 30/10/2020 18:32, Gregory Rose wrote:
The question
Fixes: 4e92542cefb7 ("ovsdb-tool: Make "show-log" convert raw JSON to
easier-to-read syntax.")
Signed-off-by: Ilya Maximets
---
ovsdb/ovsdb-tool.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ovsdb/ovsdb-tool.c b/ovsdb/ovsdb-tool.c
index 30d0472b2..1b49b6fc8 100644
---
AddressSanitizer reports this as a leak.
Let's just free the memory before exiting to avoid the noise.
'stream_close()' doesn't update the pointer, so this will not
change the return value.
Signed-off-by: Ilya Maximets
---
tests/test-stream.c | 1 +
1 file changed, 1 insertion(+)
diff --git
It is important to have memory reports in logs to track the state
of OVN daemons. With this change we will see the dynamic of the
memory consumption.
We have no any specific information to report yet, but we have to
call memory_report() to reply to all the incoming 'memory/show'
requests.
Not
On Thu, Dec 17, 2020 at 6:28 AM Mark Michelson wrote:
>
> On 12/17/20 8:56 AM, Dumitru Ceara wrote:
> > On 12/17/20 2:30 PM, Numan Siddique wrote:
> >> On Thu, Dec 17, 2020 at 3:47 PM Dumitru Ceara
wrote:
> >>>
> >>> On 12/17/20 10:23 AM, Dumitru Ceara wrote:
> The incremental processing
Hello all,
Say, ovn-nbctl is started in daemon mode with options set for certs, and
those certs do not exist on the file system. For example, in the following
invocation assume that `/ovn-cert` folder is empty
ovn-nbctl -vconsole:dbg --pidfile=/tmp/ovn-nbctl.pid --db=ssl:10.0.64.7:6641
Let me know if you have any questions or comments about it.
Paul O'Connor | Information Technology | Nott Company | 651-415-3436
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Bleep bloop. Greetings Dumitru Ceara, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
build:
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I ./include -I ./include -I ./ovn -I
./include -I
Bleep bloop. Greetings Dumitru Ceara, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
build:
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I ./include -I ./include -I ./ovn -I
./include -I
On 12/17/20 3:28 PM, Mark Michelson wrote:
> On 12/17/20 8:56 AM, Dumitru Ceara wrote:
>> On 12/17/20 2:30 PM, Numan Siddique wrote:
>>> On Thu, Dec 17, 2020 at 3:47 PM Dumitru Ceara wrote:
On 12/17/20 10:23 AM, Dumitru Ceara wrote:
> The incremental processing engine implementation
The incremental processing engine implementation is such that if an
input node gets updated but the output node doesn't have a change
handler for it then the output node is immediately recomputed. That is,
no other input change handlers are executed.
In case of the en_physical_flow_changes node,
The incremental processing engine implementation is such that if an
input node gets updated but the output node doesn't have a change
handler for it then the output node is immediately recomputed. That is,
no other input change handlers are executed.
In case of the en_physical_flow_changes node,
On Thu, Dec 17, 2020 at 6:55 AM Ilya Maximets wrote:
IIRC, during the conference Han mentioned that they are relying on OOT
> module
> for STT support. And I also noticed a patch from Vitaly to fix some issue
> in STT part of the kernel module. Both CC-ed.
>
> Han, Vitaly, do you have some
On Thu, Dec 17, 2020 at 10:23 AM Dumitru Ceara wrote:
> The incremental processing engine implementation is such that if an
> input node gets updated but the output node doesn't have a change
> handler for it then the output node is immediately recomputed. That is,
> no other input change
On 12/17/20 8:56 AM, Dumitru Ceara wrote:
On 12/17/20 2:30 PM, Numan Siddique wrote:
On Thu, Dec 17, 2020 at 3:47 PM Dumitru Ceara wrote:
On 12/17/20 10:23 AM, Dumitru Ceara wrote:
The incremental processing engine implementation is such that if an
input node gets updated but the output
On Mon, Dec 14, 2020 at 8:37 PM Ilya Maximets wrote:
>
> There could be hundreds or thousands of ct zones in external-ids map.
> Iteration over all of them and reconstruction of the whole new map
> is unnecessary and only hurts performance of both ovn-controller and
> ovsdb-server on the node.
On 12/17/20 2:30 PM, Numan Siddique wrote:
> On Thu, Dec 17, 2020 at 3:47 PM Dumitru Ceara wrote:
>>
>> On 12/17/20 10:23 AM, Dumitru Ceara wrote:
>>> The incremental processing engine implementation is such that if an
>>> input node gets updated but the output node doesn't have a change
>>>
On Thu, Dec 17, 2020 at 3:47 PM Dumitru Ceara wrote:
>
> On 12/17/20 10:23 AM, Dumitru Ceara wrote:
> > The incremental processing engine implementation is such that if an
> > input node gets updated but the output node doesn't have a change
> > handler for it then the output node is immediately
Hi Flavio,
The patch below has been in the tree for a while:
https://git.netfilter.org/conntrack-tools/commit/?id=a08af5d26297eb85218a3c3a9e0991001a88cf10
It will be included in the next release.
Thanks.
On Wed, Dec 16, 2020 at 05:25:46PM -0300, Flavio Leitner wrote:
>
> This email has 'To'
On 11/23/20 3:12 PM, Ilya Maximets wrote:
> Too big userdata could overflow netlink message leading to out-of-bound
> memory accesses or assertion while formatting nested actions.
>
> Fix that by checking the saize and returning correct error code.
>
> Credit to OSS-Fuzz.
>
> Reported-at:
On 12/16/20 9:37 PM, Flavio Leitner wrote:
> On Sun, Nov 29, 2020 at 02:30:29AM +0100, Ilya Maximets wrote:
>> On 11/12/20 6:04 PM, Gregory Rose wrote:
>>>
>>>
>>> On 11/12/2020 5:10 AM, Mark Gray wrote:
On 30/10/2020 18:32, Gregory Rose wrote:
>
> The question is whether there is any
On 12/17/20 9:20 AM, Eelco Chaudron wrote:
>
>
> On 16 Dec 2020, at 21:04, Flavio Leitner wrote:
>
>> On Mon, Oct 12, 2020 at 07:38:38AM -0400, Eelco Chaudron wrote:
>>> Currently, userspace conntrack only tracks TCP, UDP, and ICMP, and all
>>> other IP protocols are discarded, and the +inv
On 12/17/20 10:23 AM, Dumitru Ceara wrote:
> The incremental processing engine implementation is such that if an
> input node gets updated but the output node doesn't have a change
> handler for it then the output node is immediately recomputed. That is,
> no other input change handlers are
On 17 Dec 2020, at 8:18, Martin Varghese wrote:
> From: Martin Varghese
>
> There are various L3 encapsulation standards using UDP being discussed to
> leverage the UDP based load balancing capability of different networks.
> MPLSoUDP (__ https://tools.ietf.org/html/rfc7510) is one among
The incremental processing engine implementation is such that if an
input node gets updated but the output node doesn't have a change
handler for it then the output node is immediately recomputed. That is,
no other input change handlers are executed.
In case of the en_physical_flow_changes node,
--
*Hello Dear,*
*I am bringing to your attention the ongoing fund relief program to help
small, locally owned businesses and affected families due to the covid-19.
The grant and loan program offer no-interest because the IMF feels a deep
sense of responsibility knowing that large and small
EMF ID:40986935647
IMPORTANT NOTICE: Do not SEND your BANK details to anyone. EMF Donation will
not request for your bank Details.
You have been approved to claim a total sum of 1,000,000.00 AED (One Million
Emirati Dirham) attached to FILE NO: EAAL/9080118308/04.
Kindly proof that this
On 16 Dec 2020, at 21:04, Flavio Leitner wrote:
On Mon, Oct 12, 2020 at 07:38:38AM -0400, Eelco Chaudron wrote:
Currently, userspace conntrack only tracks TCP, UDP, and ICMP, and
all
other IP protocols are discarded, and the +inv state is returned.
This
is not in line with the kernel
63 matches
Mail list logo