Thanks Ben and Ilya.
I will incorporate the other changes.
I just have below comments.
>> @@ -2427,8 +2474,13 @@ odp_actions_from_string(const char *s, const struct
>> simap *port_names,
>> struct ofpbuf *actions)
>> {
>> size_t old_size;
>> +struct ovs_action
On Thu, Jan 24, 2019 at 07:55:51AM +1300, Kees Cook wrote:
> On Thu, Jan 24, 2019 at 4:44 AM Jani Nikula
> wrote:
> >
> > On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> > > On Wed, 23 Jan 2019, Jani Nikula wrote:
> > >> On Wed, 23 Jan 2019, Greg KH wrote:
> > >> > On Wed, Jan 23, 2019 at 03:03:
Declare ovs key structures using macros to enable retrieving fields
information, with no functional change.
Signed-off-by: Eli Britstein
Reviewed-by: Roi Dayan
---
include/uapi/linux/openvswitch.h | 102 ++-
1 file changed, 69 insertions(+), 33 deletions(-)
On Wednesday, January 23, 2019 6:04 AM, Kees Cook wrote
>
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
On 24.01.2019 11:04, Anju Thomas wrote:
> Thanks Ben and Ilya.
> I will incorporate the other changes.
>
> I just have below comments.
>
>>> @@ -2427,8 +2474,13 @@ odp_actions_from_string(const char *s, const struct
>>> simap *port_names,
>>> struct ofpbuf *actions)
>>>
On 23.01.2019 23:09, Ben Pfaff wrote:
> Just a style fix.
>
> With this patch, the following reports no hits:
>
> git ls-files | grep '\.[ch]$' | grep -vE 'datapath|sflow' | xargs grep -n //
> | grep -vE "http|s/|'|\""
I'd like this line wrapped. For example, like this:
git ls-files | grep '
On Wed, Jan 23, 2019 at 12:13:25PM -0800, Ben Pfaff wrote:
> I'm not so happy about reverting without having the followup ready. How
> close are we to having the followup? Basically we've got two problems
> here. Without the revert, we have one of them; with the revert, we have
> the other one.
On Mon, Jan 21, 2019 at 7:06 AM Miguel Angel Ajo Pelayo
wrote:
>
>
>
> On Mon, Jan 21, 2019 at 4:02 PM Numan Siddique wrote:
>>
>>
>> Hi Han,
>>
>> I have addressed your comments. But before posting the patch I wanted to get
>> an opinion
>> on the HA support for these external ports.
>>
>> The
DPDK 18.11 builds using the more modern meson build system no more
provide the -ldpdk linker script. Instead it is expected to use
pkgconfig for linker options as well.
This change will set DPDK_LIB from pkg-config (if pkg-config was
available) and since that already carries the whole-archive flag
On Thu, Jan 24, 2019 at 5:38 PM Christian Ehrhardt
wrote:
>
> DPDK 18.11 builds using the more modern meson build system no more
> provide the -ldpdk linker script. Instead it is expected to use
> pkgconfig for linker options as well.
A single patch didn't seem right for a 0/1 into, but let me ad
On Thu, 2019-01-24 at 17:38 +0100, Christian Ehrhardt wrote:
> DPDK 18.11 builds using the more modern meson build system no more
> provide the -ldpdk linker script. Instead it is expected to use
> pkgconfig for linker options as well.
>
> This change will set DPDK_LIB from pkg-config (if pkg-conf
Hello,
I'm trying to reduce the forwarding state in switches.
I have a simple topology consists of 2 switches and 2 servers
H1>S1>S2>H2
Ι have entered those 2 flows
*Routing header insertion at s1*
sudo ovs-ofctl add-flow s1
dl_type=0x800,nw_dst=10.0.0.2,actions=mod_dl_src:20:00
On Thu, Jan 24, 2019 at 07:34:02PM +0200, GEORGIOS PAPATHANAIL wrote:
> Hello,
>
> I'm trying to reduce the forwarding state in switches.
> I have a simple topology consists of 2 switches and 2 servers
>
> H1>S1>S2>H2
>
>
> Ι have entered those 2 flows
>
> *Routing header insertion
Hi Greg,
0-day Robot writes:
> Bleep bloop. Greetings Greg Rose, 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:
> Failed to merge in the changes.
> Patch failed at 0001
> On Jan 21, 2019, at 10:23 AM, Gregory Rose wrote:
>
> On 1/16/2019 8:03 AM, Aaron Conole wrote:
>> Following code looks like it might be wrong. I don't know much about
>> the way the stt infrastructure is being used, so feel free to ignore if
>> it is expected to return NETDEV_TX_OK even in e
On Thu, Jan 24, 2019 at 9:20 PM Han Zhou wrote:
> On Mon, Jan 21, 2019 at 7:06 AM Miguel Angel Ajo Pelayo
> wrote:
> >
> >
> >
> > On Mon, Jan 21, 2019 at 4:02 PM Numan Siddique
> wrote:
> >>
> >>
> >> Hi Han,
> >>
> >> I have addressed your comments. But before posting the patch I wanted
> to
Just a gentle reminder on some feedback about the approach in the first two
patches in the series :)
Thanks
Numan
On Thu, Jan 10, 2019 at 11:29 PM wrote:
> From: Numan Siddique
>
> This is an RFC series to address the MTU issues for OVN reported
> here [1].
>
> To address this issue, a new OV
On Thu, Jan 24, 2019 at 10:56 AM Numan Siddique wrote:
>
>
>
> On Thu, Jan 24, 2019 at 9:20 PM Han Zhou wrote:
>>
>> On Mon, Jan 21, 2019 at 7:06 AM Miguel Angel Ajo Pelayo
>> wrote:
>> >
>> >
>> >
>> > On Mon, Jan 21, 2019 at 4:02 PM Numan Siddique wrote:
>> >>
>> >>
>> >> Hi Han,
>> >>
>> >>
On 1/24/2019 10:21 AM, Aaron Conole wrote:
Hi Greg,
0-day Robot writes:
Bleep bloop. Greetings Greg Rose, 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:
Failed to merge in the c
From: Han Zhou
Signed-off-by: Han Zhou
---
ovsdb/ovsdb-client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ovsdb/ovsdb-client.c b/ovsdb/ovsdb-client.c
index 83c3c12..0215357 100644
--- a/ovsdb/ovsdb-client.c
+++ b/ovsdb/ovsdb-client.c
@@ -1267,7 +1267,7 @@ ovsdb_client_
From: Han Zhou
Ommiting the parameter names in prototypes, as suggested by coding
style: Omit parameter names from function prototypes when the names
do not give useful information.
Adjust orders of parameters as suggested by coding style.
Signed-off-by: Han Zhou
---
ovsdb/jsonrpc-server.c |
From: Han Zhou
Current ovsdb monitor maintains pending changes through an incremental
integer to figure out if the set of changes should be flushed. And it
uses number 0 to represent that the change set contains all data for
initial client population. It is a smart way but it prevents further
ex
From: Han Zhou
Maintaining last N (n = 100) transactions in memory, which will be
used for future patches for generating monitor data from any point
in this N transactions.
Signed-off-by: Han Zhou
---
ovsdb/ovsdb-server.c | 8 +
ovsdb/ovsdb.h| 10 ++
ovsdb/transaction.c | 97
From: Han Zhou
Use monitor_cond_since to request changes after last version of local
data when connection to server is reset, without clearing the local
data. It falls back to clearing and repopulate all the data when
the requested id cannot be fulfilled by the server.
Signed-off-by: Han Zhou
-
From: Han Zhou
Use monitor_cond_since in C IDL. If it is not supported by server,
fall back to old method (monitor_cond, or monitor).
Signed-off-by: Han Zhou
---
lib/ovsdb-idl.c | 206 +++-
1 file changed, 158 insertions(+), 48 deletions(-)
From: Han Zhou
Support the new monitor method monitor_cond_since so that a client
can request monitoring start from a specific point instead of always
from beginning. This will reduce the cost at scenarios when server
is restarted/failed-over but client still has all existing data. In
these scena
In scalability test with ovn-scale-test, ovsdb-server SB load is not a
problem at least with 1k HVs. However, if we restart the ovsdb-server,
depending on the number of HVs and scale of logical objects, e.g. the
number of logical ports, ovsdb-server of SB become an obvious bottleneck.
In our test
(re-send this cover letter because it was blocked by the mailing-list saying:
"The message headers matched a filter rule")
In scalability test with ovn-scale-test, ovsdb-server SB load is not a
problem at least with 1k HVs. However, if we restart the ovsdb-server,
depending on the number of HVs an
(re-send this cover letter because it was blocked by the mailing-list saying:
"The message headers matched a filter rule")
In scalability test with ovn-scale-test, ovsdb-server SB load is not a
problem at least with 1k HVs. However, if we restart the ovsdb-server,
depending on the number of HVs an
The Python IDL implementation supports ovsdb cluster connections.
This patch is a follow up to commit 31e434fc98, it adds the option of
connecting to the leader (the default) in the Raft-based cluster. It mimics
the exisiting C IDL support for clusters introduced in commit 1b1d2e6daa.
The _Server
30 matches
Mail list logo