Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

On Fri, Apr 06, 2018 at 06:37:16PM -0400, Aaron Conole wrote: > There's lots of ways to skin this cat. I'd probably be more apt to > support either the latch/seq approach (because it mirrors the existing > implementation), and if we find it isn't good enough - improve it. That's my usual

Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

Ben Pfaff writes: > On Fri, Apr 06, 2018 at 04:13:34PM -0500, Mark Michelson wrote: >> On 04/06/2018 02:50 PM, Ben Pfaff wrote: >> >On Fri, Apr 06, 2018 at 02:27:16PM -0500, Mark Michelson wrote: >> >>On 04/06/2018 02:18 PM, Mark Michelson wrote: >> >>>On 04/06/2018 12:28 PM, Ben

Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

On Fri, Apr 06, 2018 at 04:13:34PM -0500, Mark Michelson wrote: > On 04/06/2018 02:50 PM, Ben Pfaff wrote: > >On Fri, Apr 06, 2018 at 02:27:16PM -0500, Mark Michelson wrote: > >>On 04/06/2018 02:18 PM, Mark Michelson wrote: > >>>On 04/06/2018 12:28 PM, Ben Pfaff wrote: > On Fri, Apr 06, 2018

Re: [ovs-dev] [PATCH] OF1.5/EXT-334 OXS/Extensible Flow Entry Statistics Support

On Wed, Feb 28, 2018 at 08:05:56PM +0530, SatyaValli wrote: > From: SatyaValli > > This Patch provides implementation Existing flow entry statistics are > redefined as standard OXS(OpenFlow Extensible Statistics) fields for > displaying the arbitrary flow stats.The

Re: [ovs-dev] [RFC v2 01/10] ovn-controller: Incremental processing engine

Adding ML back :) On Fri, Apr 6, 2018 at 2:51 PM, Mark Michelson wrote: > > Hi Han, I'm slowly making my way through this patch series. So far, I have a pretty small finding. See below. > > > On 03/22/2018 01:42 PM, Han Zhou wrote: >> >> This patch implements the engine

Re: [ovs-dev] [PATCH v2] ovn: Avoid nb_cfg update notification flooding

On Fri, Apr 6, 2018 at 1:54 PM, Ben Pfaff wrote: > > Thanks for working on making OVN faster and scale better. > > I see what you mean about how nb_cfg can be a scale problem. Really, > each hypervisor only cares about its own row, but each of them is being > notified about the

[ovs-dev] raft ovsdb clustering with scale test

Hi Ben/Numan: So I went ahead to try out clustered db in scale env and results are not as expected. OVS branch used is master; commit-id(2062840612904ff0873d46b2f4f226bc23f2296d) Setup is uing 3 nodes. Also disabled inactivity_probe, ovn-nbctl

Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

On 04/06/2018 02:50 PM, Ben Pfaff wrote: On Fri, Apr 06, 2018 at 02:27:16PM -0500, Mark Michelson wrote: On 04/06/2018 02:18 PM, Mark Michelson wrote: On 04/06/2018 12:28 PM, Ben Pfaff wrote: On Fri, Apr 06, 2018 at 10:16:24AM -0700, Justin Pettit wrote: In some environments, builds would

Re: [ovs-dev] [PATCH v2] ovn: Avoid nb_cfg update notification flooding

Thanks for working on making OVN faster and scale better. I see what you mean about how nb_cfg can be a scale problem. Really, each hypervisor only cares about its own row, but each of them is being notified about the current value in every row. Ideally, we want the HVs to be able to say to

Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

On 04/06/2018 02:53 PM, Justin Pettit wrote: On Apr 6, 2018, at 12:27 PM, Mark Michelson wrote: I just had a look, and unfortunately, the current code doesn't translate directly to a latch. The reason is that you can't control the data that is sent to and read from the

Re: [ovs-dev] Imperative vs. Declarative abstraction at the SB DB

On Fri, Mar 30, 2018 at 05:15:57AM +0200, Liran Schour wrote: > I wanted to raise a question that I came a cross. Maybe the community > already dealt with it. > > The ovn-northd translates the CMS's commands that resides in the NB DB > into the SB DB. > > Specifically it produces the

Re: [ovs-dev] [PATCH] json.at: Avoid to run $PYTHON when python is not available

On Fri, Apr 06, 2018 at 08:08:24PM +0200, Timothy Redaelli wrote: > This commit is needed since autotest tries to run AT_XFAIL_IF when > AT_SKIP_IF condition is true too. > > Currently HAVE_PYTHON is required, but this may change in the future > since many distributions are migrating to python3

Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

> On Apr 6, 2018, at 12:27 PM, Mark Michelson wrote: > > I just had a look, and unfortunately, the current code doesn't translate > directly to a latch. The reason is that you can't control the data that is > sent to and read from the latch. It's essentially a boolean of

Re: [ovs-dev] [PATCH v4 0/6] Add minimum network namespace support.

On Fri, Apr 06, 2018 at 04:42:34PM -0300, Flavio Leitner wrote: > On Wed, Apr 04, 2018 at 10:07:08AM -0700, Ben Pfaff wrote: > > On Tue, Apr 03, 2018 at 09:48:55PM -0300, Flavio Leitner wrote: > > > On Sat, Mar 31, 2018 at 01:23:20PM -0700, Ben Pfaff wrote: > > > > Second, I think that it is

Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

On Fri, Apr 06, 2018 at 02:27:16PM -0500, Mark Michelson wrote: > On 04/06/2018 02:18 PM, Mark Michelson wrote: > >On 04/06/2018 12:28 PM, Ben Pfaff wrote: > >>On Fri, Apr 06, 2018 at 10:16:24AM -0700, Justin Pettit wrote: > >>>In some environments, builds would fail with the following error: >

Re: [ovs-dev] [PATCH v4 0/6] Add minimum network namespace support.

On Wed, Apr 04, 2018 at 10:07:08AM -0700, Ben Pfaff wrote: > On Tue, Apr 03, 2018 at 09:48:55PM -0300, Flavio Leitner wrote: > > On Sat, Mar 31, 2018 at 01:23:20PM -0700, Ben Pfaff wrote: > > > Second, I think that it is possible to open a Netlink socket for a > > > particular namespace, which

Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

On 04/06/2018 02:18 PM, Mark Michelson wrote: On 04/06/2018 12:28 PM, Ben Pfaff wrote: On Fri, Apr 06, 2018 at 10:16:24AM -0700, Justin Pettit wrote: In some environments, builds would fail with the following error:    lib/stopwatch.c: In function ‘stopwatch_exit’:    lib/stopwatch.c:448:5:

Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

On 04/06/2018 12:28 PM, Ben Pfaff wrote: On Fri, Apr 06, 2018 at 10:16:24AM -0700, Justin Pettit wrote: In some environments, builds would fail with the following error: lib/stopwatch.c: In function ‘stopwatch_exit’: lib/stopwatch.c:448:5: error: ignoring return value of ‘write’,

[ovs-dev] [PATCH] json.at: Avoid to run $PYTHON when python is not available

This commit is needed since autotest tries to run AT_XFAIL_IF when AT_SKIP_IF condition is true too. Currently HAVE_PYTHON is required, but this may change in the future since many distributions are migrating to python3 as default python (like Arch Linux or Fedora) and so it can be a good idea to

Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

Thanks Justin! Acked-by: Mark Michelson On 04/06/2018 12:16 PM, Justin Pettit wrote: In some environments, builds would fail with the following error: lib/stopwatch.c: In function ‘stopwatch_exit’: lib/stopwatch.c:448:5: error: ignoring return value of ‘write’,

Re: [ovs-dev] [PATCH] ofproto-dpif: Init ukey->dump_seq to zero

[also CCing Joe on the chance that he wants to comment] On Fri, Apr 06, 2018 at 09:34:38AM +, Jan Scheurich wrote: > > -Original Message- > > From: Ben Pfaff [mailto:b...@ovn.org] > > Sent: Wednesday, 04 April, 2018 22:28 > > > > Oh, that's weird. It's as if I didn't read the patch.

Re: [ovs-dev] [PATCH 2/2] OVN: add icmp6 action to ovn acl reject support

On Fri, Apr 06, 2018 at 07:05:33PM +0200, Lorenzo Bianconi wrote: > Whenever the acl reject rule is hit by an IPv6 packet send back > an ICMPv6 destination unreachable packet using the icmp6 action > > Signed-off-by: Lorenzo Bianconi Thank you for implementing this.

Re: [ovs-dev] [PATCH 1/2] OVN: add icmp6{} action support

On Fri, Apr 06, 2018 at 07:05:32PM +0200, Lorenzo Bianconi wrote: > icmp6 action is used to replace the IPv6 packet been processed with > an ICMPv6 packet initialized based on incoming IPv6 one. > Ethernet and IPv6 fields not listed are not changed: > - ip.proto = 58 (ICMPv6) > - ip.ttl = 255 > -

Re: [ovs-dev] [PATCH v2 0/2] Correct handling of double encap and decap actions

Yes that fix should be applied to branches 2.9 and 2.8. I checked that it applies and passes all unit tests pass. On branch-2.8 the patch for nsh.at patch must be slightly retrofitted as the datapath action names changed from encap_nsh/decap_nsh to push_nsh/pop_nsh and the nsh_ttl field was

Re: [ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

On Fri, Apr 06, 2018 at 10:16:24AM -0700, Justin Pettit wrote: > In some environments, builds would fail with the following error: > > lib/stopwatch.c: In function ‘stopwatch_exit’: > lib/stopwatch.c:448:5: error: ignoring return value of ‘write’, declared > with attribute

[ovs-dev] [PATCH] stopwatch: Explicitly ignore write() return value.

In some environments, builds would fail with the following error: lib/stopwatch.c: In function ‘stopwatch_exit’: lib/stopwatch.c:448:5: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Werror=unused-result] write(stopwatch_pipe[1], , sizeof pkt);

[ovs-dev] [PATCH 2/2] OVN: add icmp6 action to ovn acl reject support

Whenever the acl reject rule is hit by an IPv6 packet send back an ICMPv6 destination unreachable packet using the icmp6 action Signed-off-by: Lorenzo Bianconi --- ovn/northd/ovn-northd.c | 25 ++--- tests/ovn.at| 20

[ovs-dev] [PATCH 1/2] OVN: add icmp6{} action support

icmp6 action is used to replace the IPv6 packet been processed with an ICMPv6 packet initialized based on incoming IPv6 one. Ethernet and IPv6 fields not listed are not changed: - ip.proto = 58 (ICMPv6) - ip.ttl = 255 - icmp6.type = 1 (destination unreachable) - icmp6.code = 1 (communication

[ovs-dev] [PATCH 0/2] add icmp6 action support to ovn acl framework

Lorenzo Bianconi (2): OVN: add icmp6{} action support OVN: add icmp6 action to ovn acl reject support include/ovn/actions.h | 7 + ovn/controller/pinctrl.c | 72 ++- ovn/lib/actions.c | 22 +++ ovn/northd/ovn-northd.c

Re: [ovs-dev] [PATCH v2 0/2] Correct handling of double encap and decap actions

On Fri, Apr 06, 2018 at 09:35:48AM -0700, Ben Pfaff wrote: > On Thu, Apr 05, 2018 at 04:11:02PM +0200, Jan Scheurich wrote: > > Recent tests with NSH encap have shown that the translation of multiple > > subsequent encap() or decap() actions was incorrect. This patch set > > corrects the handling

Re: [ovs-dev] [PATCH v2 0/2] Correct handling of double encap and decap actions

On Thu, Apr 05, 2018 at 04:11:02PM +0200, Jan Scheurich wrote: > Recent tests with NSH encap have shown that the translation of multiple > subsequent encap() or decap() actions was incorrect. This patch set > corrects the handling and adds a unit test for NSH to cover two NSH > and one Ethernet

Re: [ovs-dev] [branch-2.9 PATCH 1/2] netdev-dpdk: Free mempool only when no in-use mbufs.

>> DPDK mempools are freed when they are no longer needed. >> This can happen when a port is removed or a port's mtu is reconfigured so >> that a new mempool is used. >> >> It is possible that an mbuf is attempted to be returned to a freed mempool >> from NIC Tx queues and this can lead to a

Re: [ovs-dev] kernel panic

On 4/5/2018 11:47 AM, Nicolas Bouliane via dev wrote: Hey folks, We have experienced a kernel panic and we are trying to nail down the culprit: NIC, network stack itself, OvS datapath, etc. I can provide more info in a subsequent email, but at first I just wanted to have a couple of eye balls

Re: [ovs-dev] [PATCH v10 1/3] netdev: Add optional qfill output parameter to rxq_recv()

> > @@ -1846,11 +1846,24 @@ netdev_dpdk_vhost_rxq_recv(struct netdev_rxq *rxq, > > batch->count = nb_rx; > > dp_packet_batch_init_packet_fields(batch); > > > > +if (qfill) { > > +if (nb_rx == NETDEV_MAX_BURST) { > > +/* The DPDK API returns a uint32_t which often

Re: [ovs-dev] [PATCH v1] tests: Added NSH related unit test cases for datapath

On 4/4/2018 10:23 AM, Ben Pfaff wrote: On Thu, Mar 29, 2018 at 04:46:09PM -0700, Ashish Varma wrote: Added test cases for encap, decap, replace and forwarding of NSH packets. Also added a python script 'sendpkt.py' to send hex ethernet frames. Signed-off-by: Ashish Varma

Re: [ovs-dev] [PATCH v10 1/3] netdev: Add optional qfill output parameter to rxq_recv()

Oh, how I missed that... Comment inline. Best regards, Ilya Maximets. On 18.03.2018 20:55, Jan Scheurich wrote: > If the caller provides a non-NULL qfill pointer and the netdev > implemementation supports reading the rx queue fill level, the rxq_recv() > function returns the remaining number of

Re: [ovs-dev] [RFC 0/2] dpdk: minor refactor of the initialization step

So just from a deployment tools point of view I would like to point out that This change could break existing workflow that deploy ovs in a docker container. Kolla ansible assumes that if the docker ovs_vswitchd container is still running that the is infact running in dpdk mode when we set

Re: [ovs-dev] [PATCH] ofproto-dpif: Init ukey->dump_seq to zero

> -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Wednesday, 04 April, 2018 22:28 > > Oh, that's weird. It's as if I didn't read the patch. Maybe I just > read some preliminary version in another thread. > > Anyway, you're totally right. I applied this to master.