Dernière Ligne droite pour de bonnes vibrations lors de la 5èm édition
du Nomade Reggae Festival, l'évènement de l'été en Haute - Savoie, Les 2,3 et
4 Août à Frangy (74)
A 30 Minutes de Genève, d'Annecy, à 1H30 de Lyon et de Grenoble
Avec au
BTW, offload features are on in my test client1 and server1 (iperf server)
vagrant@client1:~$ ethtool -k enp0s8
Features for enp0s8:
rx-checksumming: on [fixed]
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
Ilya, thank you so much, using 9K MTU for all the virtio interfaces in
transport path does help (including DPDK port), the data is here.
vagrant@client1:~$ iperf -t 60 -i 10 -c 192.168.230.101
Client connecting to 192.168.230.101, TCP
Thanks Ben!
On 7/10/2019 1:04 PM, Ben Pfaff wrote:
Thanks for the backports (William, thanks for the reviews). I applied
these to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Say an ARP entry is learnt on a OVS port and when such a port is deleted,
learnt entry should be removed from the port. It would have be aged out after
ARP ageout time. This code will clean up immediately.
Added test case(tunnel - neighbor entry add and deletion) in tunnel.at, to
verify neighbors
On Tue, Jul 09, 2019 at 02:49:18PM +0200, Dumitru Ceara wrote:
> A new action ("igmp") is added to punt IGMP packets on a specific logical
> switch datapath to ovn-controller if IGMP snooping is enabled.
I do not fully understand the new action. It is defined to take a set
of nested actions
On Tue, Jul 09, 2019 at 12:16:30PM +0200, Daniel Alvarez wrote:
> Prior to this patch, only db change aware connections were dropped
> on a read/write status change. However, current schema in OVN does
> not allow clients to monitor whether a particular DB changes this
> status. In order to
Thanks for the backports (William, thanks for the reviews). I applied
these to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On Wed, Jul 10, 2019 at 11:07:16AM -0500, Terry Wilson wrote:
> Without shutting down the SSL connection, log messages like:
>
> stream_ssl|WARN|SSL_read: unexpected SSL connection close
> jsonrpc|WARN|ssl:127.0.0.1:47052: receive error: Protocol error
> reconnect|WARN|ssl:127.0.0.1:47052:
For the series:
Acked-by: Mark Michelson
On 7/9/19 8:48 AM, Dumitru Ceara wrote:
This series introduces support for IGMP Snooping and IGMP Querier. IGMP
versions v1-v3 are supported for snooping and IGMP queries originated by
ovn-controller are general IGMPv3 queries. The rationale behind
from __future__ import print_function
import sys
from ovs import jsonrpc
from ovs import stream
from ovs.unixctl import client
URI='ssl:127.0.0.1:6641'
PRIV='sandbox/ovnnb-privkey.pem'
CERT='sandbox/ovnnb-cert.pem'
CACERT='sandbox/pki/switchca/cacert.pem'
Next meeting July 24th 1700 UTC
July 10th minutes
Attendees: Ian, Aaron, Eelco, Fouad, Johann, Scott, Simon.
===
GENERAL
===
- OVS 2.12 (Ian)
-- Dates
--- Soft Freeze entered 7th July. Will remain until the 22nd of July.
Hard freeze from the 22nd of July onwards. Only bug fixes
On 7/9/2019 1:34 PM, Harry van Haaren wrote:
This commit splits the generic hash-lookup-verify
function to its own file. In doing so, we must move
some MACRO definitions to dpif-netdev.h
Signed-off-by: Harry van Haaren
Tested-by: Malvika Gupta
Thanks Harry, some feedback below.
---
v10:
On 7/10/19 12:11 PM, Terry Wilson wrote:
An example of a reproducer script attached. If you enable SSL and OVN w/
the sandbox and run it, looking in the sandbox/nb1.log you'll see the
disconnect errors that the patch makes go away.
Hi Terry. It looks like the mailing list has eaten your
> On Fri, Jun 14, 2019 at 05:53:20PM +0200, Lorenzo Bianconi wrote:
> > The series here introduces a new table, Controller_Event, for this
> > purpose. Traffic into OVS can raise a controller() event that results in
> > a Controller_Event being written to the southbound database. The
> > intention
An example of a reproducer script attached. If you enable SSL and OVN w/
the sandbox and run it, looking in the sandbox/nb1.log you'll see the
disconnect errors that the patch makes go away.
On Wed, Jul 10, 2019 at 11:07 AM Terry Wilson wrote:
> Without shutting down the SSL connection, log
Without shutting down the SSL connection, log messages like:
stream_ssl|WARN|SSL_read: unexpected SSL connection close
jsonrpc|WARN|ssl:127.0.0.1:47052: receive error: Protocol error
reconnect|WARN|ssl:127.0.0.1:47052: connection dropped (Protocol error)
would occur whenever the socket is
On 7/10/2019 4:40 PM, Van Haaren, Harry wrote:
-Original Message-
From: Stokes, Ian
Sent: Wednesday, July 10, 2019 4:30 PM
To: Van Haaren, Harry ; d...@openvswitch.org
Cc: i.maxim...@samsung.com; malvika.gu...@arm.com
Subject: Re: [PATCH v10 1/5] dpif-netdev: implement function
On 7/9/2019 1:34 PM, Harry van Haaren wrote:
This commit moves some data-structures to be available
in the dpif-netdev.h header. This allows specific implementations
of the subtable lookup function to include just that header
file, and not require that the code exists in dpif-netdev.c
> -Original Message-
> From: Stokes, Ian
> Sent: Wednesday, July 10, 2019 4:30 PM
> To: Van Haaren, Harry ; d...@openvswitch.org
> Cc: i.maxim...@samsung.com; malvika.gu...@arm.com
> Subject: Re: [PATCH v10 1/5] dpif-netdev: implement function pointers/subtable
>
> On 7/9/2019 1:34 PM,
On 7/9/2019 1:34 PM, Harry van Haaren wrote:
This allows plugging-in of different subtable hash-lookup-verify
routines, and allows special casing of those functions based on
known context (eg: # of bits set) of the specific subtable.
Signed-off-by: Harry van Haaren
Tested-by: Malvika Gupta
On Wed, Jul 10, 2019 at 1:51 PM Ilya Maximets wrote:
>
> It became more complicated, hence needs to be documented.
>
> Signed-off-by: Ilya Maximets
> ---
>
> Applicable on top of "Quicker pmd threads reloads" patch-set:
> https://patchwork.ozlabs.org/project/openvswitch/list/?series=118588=*
>
>
On 7/10/2019 10:03 AM, Ilya Maximets wrote:
On 09.07.2019 19:19, David Marchand wrote:
We have been testing the rebalance code in different situations while
having traffic going through OVS.
Those tests have shown that part of the observed packets losses is due to
some time wasted in
On 7/10/2019 12:50 PM, Ilya Maximets wrote:
It became more complicated, hence needs to be documented.
Signed-off-by: Ilya Maximets
Thanks for taking care of this Ilya, very valuable info.
Looks fine to me.
I was just getting ready to push the quicker PMD reload series, I'll add
this as
It became more complicated, hence needs to be documented.
Signed-off-by: Ilya Maximets
---
Applicable on top of "Quicker pmd threads reloads" patch-set:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=118588=*
lib/dpif-netdev.c | 39 +++
1
> Hi, all
>
> I just use ovs as a static router in my test case, ovs is ran in vagrant VM,
> ethernet interfaces uses virtio driver, I create two ovs bridges, each one
> adds one ethernet interface, two bridges are connected by patch port, only
> default openflow rule is there.
>
> table=0,
Hättest du das gedacht? https://laumemismi1987.blogspot.nl/
___
Freu mich auf deine Nachricht
papiengu...@yahoo.com
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On 09.07.2019 19:19, David Marchand wrote:
> We have been testing the rebalance code in different situations while
> having traffic going through OVS.
> Those tests have shown that part of the observed packets losses is due to
> some time wasted in signaling/waiting for the pmd threads to reload
alt_text
Conference E-Marketing Live
Big Data, SEO, Blockchain, Social Media, UX… Quelles perspectives marketing
pour 2020 ?
Identifiez les enjeux des nouvelles tendances digitales et gardez une longueur
d’avance sur vos concurrents !
JE MINSCRIS
Conference diffusee en direct et
Ack the v4 also…
Acked-by: Eelco Chaudron
On 9 Jul 2019, at 18:19, David Marchand wrote:
pmd reloads are currently serialised in each steps calling
reload_affected_pmds.
Any pmd processing packets, waiting on a mutex etc... will make other
pmd threads wait for a delay that can be
On 09.07.2019 19:19, David Marchand wrote:
> pmd reloads are currently serialised in each steps calling
> reload_affected_pmds.
> Any pmd processing packets, waiting on a mutex etc... will make other
> pmd threads wait for a delay that can be undeterministic when syscalls
> adds up.
>
> Switch to
31 matches
Mail list logo
