On Tue, Jan 21, 2014 at 11:14 AM, Gurucharan Shetty wrote:
> On Mon, Jan 20, 2014 at 5:55 PM, Ansis Atteka wrote:
>> Without these two iptables rules (one for UDP encapsulated IPsec and
>> another for direct IPsec), ovs-vswitchd would incorrectly conclude
>> that GRE packet belonged to a plain GR
On Tue, Jan 21, 2014 at 03:06:08PM -0800, Ethan Jackson wrote:
> When compiling with -O3, GCC can no longer tell that the following
> warnings are not valid. At any rate, they're easy enough to silence.
>
> ofp-parse.c:764:45: error: 'ttl' may be used uninitialized in this
> function
>
> ofp-par
On Tue, Jan 21, 2014 at 05:58:16PM -0800, Ethan Jackson wrote:
> The AM_V_GEN macro fits more cleanly with the automake silent rules
> option. When enabled it will print "GEN " instead of simply
> echoing the command as before.
>
> Signed-off-by: Ethan Jackson
I think that the first change is O
The AM_V_GEN macro fits more cleanly with the automake silent rules
option. When enabled it will print "GEN " instead of simply
echoing the command as before.
Signed-off-by: Ethan Jackson
---
Makefile.am | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile.am b/Mak
Acked-by: Joe Stringer
On 21 January 2014 17:09, Ben Pfaff wrote:
> On Tue, Jan 21, 2014 at 05:05:27PM -0800, Ethan Jackson wrote:
> > Configure has an option which supports quieter compilation.
> >
> > Signed-off-by: Ethan Jackson
>
> Regarding the configure.ac change,
> Acked-by: Ben Pfaff
Am I missing something? This appears to be overridden by Patch #2.
On 21 January 2014 17:05, Ethan Jackson wrote:
> Signed-off-by: Ethan Jackson
> ---
> utilities/ovs-dev.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/utilities/ovs-dev.py b/utilities/ovs-dev.py
> i
On 21 January 2014 16:53, Jarno Rajahalme wrote:
> Looks ok, but as I don't parse python, I'll want to try this out
> tomorrow. Is there a place where this could be documented?
>
I think that the OptionGroup object will automatically generate the
"--help" documentation from the "help=..." param
On Tue, Jan 21, 2014 at 05:05:27PM -0800, Ethan Jackson wrote:
> Configure has an option which supports quieter compilation.
>
> Signed-off-by: Ethan Jackson
Regarding the configure.ac change,
Acked-by: Ben Pfaff
I don't use ovs-dev.py so I'll leave reviewing that to someone who
does.
Configure has an option which supports quieter compilation.
Signed-off-by: Ethan Jackson
---
configure.ac | 2 ++
utilities/ovs-dev.py | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 9b6c69e..19c095e 100644
--- a/configure.ac
+++ b/
Signed-off-by: Ethan Jackson
---
utilities/ovs-dev.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utilities/ovs-dev.py b/utilities/ovs-dev.py
index 7b69094..80f0b80 100755
--- a/utilities/ovs-dev.py
+++ b/utilities/ovs-dev.py
@@ -63,7 +63,7 @@ def conf():
configure =
Looks ok, but as I don't parse python, I'll want to try this out tomorrow. Is
there a place where this could be documented?
Jarno
> On Jan 21, 2014, at 3:06 PM, Ethan Jackson wrote:
>
> Signed-off-by: Ethan Jackson
> ---
> utilities/ovs-dev.py | 10 +-
> 1 file changed, 9 insertion
Acked-by: Jarno Rajahalme
> On Jan 21, 2014, at 3:06 PM, Ethan Jackson wrote:
>
> This makes it easier for development tools including "perf", give
> clean backtraces on x86-64 systems.
>
> Signed-off-by: Ethan Jackson
> ---
> utilities/ovs-dev.py | 2 +-
> 1 file changed, 1 insertion(+), 1 d
Acked-by: Jarno Rajahalme
> On Jan 21, 2014, at 3:06 PM, Ethan Jackson wrote:
>
> When compiling with -O3, GCC can no longer tell that the following
> warnings are not valid. At any rate, they're easy enough to silence.
>
> ofp-parse.c:764:45: error: 'ttl' may be used uninitialized in this
>
This makes it easier for development tools including "perf", give
clean backtraces on x86-64 systems.
Signed-off-by: Ethan Jackson
---
utilities/ovs-dev.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utilities/ovs-dev.py b/utilities/ovs-dev.py
index 7b69094..39af37a 10075
When compiling with -O3, GCC can no longer tell that the following
warnings are not valid. At any rate, they're easy enough to silence.
ofp-parse.c:764:45: error: 'ttl' may be used uninitialized in this
function
ofp-parse.c:752:17: error: 'ecn' may be used uninitialized in this
function
Signed-
Signed-off-by: Ethan Jackson
---
utilities/ovs-dev.py | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/utilities/ovs-dev.py b/utilities/ovs-dev.py
index 39af37a..dff1a3a 100755
--- a/utilities/ovs-dev.py
+++ b/utilities/ovs-dev.py
@@ -28,7 +28,7 @@ BUILD_GCC = OVS_SRC
Fetching the number of flows in the datapath has been causing
unnecessary contention on the kernel ovs_lock in recent TCP CRR tests.
This patch caches this number for up to 100ms in the userspace to reduce
such kernel calls.
Signed-off-by: Joe Stringer
Co-authored-by: Jarno Rajahalme
Signed-off-
Changes are committed to master, thx.~
On Tue, Jan 21, 2014 at 11:25 AM, Alex Wang wrote:
> Thanks Ethan, all make sense, I'll learn how to apply it myself.
>
>
>
> On Tue, Jan 21, 2014 at 11:01 AM, Ethan Jackson wrote:
>
>> > +bfd->ip_src = htonl(0xA9FE0100); /* 169.254.1.0. */
>> > +
On Wed, Jan 8, 2014 at 4:15 PM, Jarno Rajahalme wrote:
> 'perf' report on current master shows that kernel-side locking is
> taking more than 20% of the overall OVS execution time under TCP_CRR
> tests with flow tables that make all new connections go to userspace
> and that create huge amount of
Thanks Ethan, all make sense, I'll learn how to apply it myself.
On Tue, Jan 21, 2014 at 11:01 AM, Ethan Jackson wrote:
> > +bfd->ip_src = htonl(0xA9FE0100); /* 169.254.1.0. */
> > +bfd->ip_dst = htonl(0xA9FE0101); /* 169.254.1.1. */
> > +
>
> I don't see a reason to set the def
An upcoming patch will introduce another, completely unrelated seq to
'struct nl_dump'. Giving this one a better name should reduce confusion.
Signed-off-by: Joe Stringer
---
v2: First post
---
lib/netlink-socket.c |6 +++---
lib/netlink-socket.h |2 +-
2 files changed, 4 insertions(+),
The 'dpif_' parameter of dpif_linux_flow_dump_next() was marked as
OVS_UNUSED, even though it's passed down to dpif_linux_flow_get__().
Signed-off-by: Joe Stringer
---
v2: First post
---
lib/dpif-linux.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dpif-linux.c b/li
Recent changes to the flow_dump_next() interface have made it the
responsibility of the dpif implementation to track error status over a
flow dump operation.
This patch removes status tracking from 'struct dpif_flow_dump', allowing
multiple threads to call dpif_flow_dump_next() and track their sta
This patch makes all of the users of 'struct nl_dump' allocate their own
buffers to pass down to nl_dump_next(). This paves the way for allowing
multithreaded flow dumping.
Signed-off-by: Joe Stringer
---
The previous version was acked-by Ben, but several patches were merged in,
so it needs fresh
On Tue, Jan 21, 2014 at 10:11:16AM -0800, Gurucharan Shetty wrote:
> On Tue, Jan 21, 2014 at 10:04 AM, Ben Pfaff wrote:
> > On Tue, Jan 21, 2014 at 10:02:09AM -0800, Gurucharan Shetty wrote:
> >> On Tue, Jan 7, 2014 at 10:31 AM, Ben Pfaff wrote:
> >> > On Mon, Jan 06, 2014 at 02:40:34PM -0800, Gu
Currently, we have a single thread (the 'flow_dumper') that fetches the flows
from the datapath and distributes them to revalidator threads. To clean up the
code (and provide a small performance benefit), we are looking at removing this
flow_dumper thread, and have each revalidator fetch flows from
This patch modifies 'struct nl_dump' and nl_dump_next() to allow
multiple threads to share the same nl_dump. These changes are targeted
around synchronizing dump status between multiple callers, and
allowing callers to fully process their existing buffers before
determining whether to stop fetching
This patch separates the structures for thread-local flow dump state
("state") from the shared flow dump state ("iter") in dpif-linux and
dpif-netdev. Future patches will make use of this to allow multiple
threads to dump flows from the same flow dump operation.
Signed-off-by: Joe Stringer
---
v2
This patch makes it the caller's responsibility to initialize a
per-thread 'state' object and pass it down to the dpif_flow_dump_next()
implementation. The implementation can expect to be called from multiple
threads with the same 'iter' and different 'state' objects.
When flow_dump_next() returns
On Tue, Jan 21, 2014 at 9:54 AM, Jesse Gross wrote:
> On Wed, Jan 15, 2014 at 3:46 PM, Luigi Rizzo wrote:
> > On Wed, Jan 15, 2014 at 03:10:35PM -0800, Jesse Gross wrote:
> >> On Sat, Jan 11, 2014 at 4:33 PM, Luigi Rizzo
> wrote:
> >> > Hi,
> >> > in porting the ovs kernel code to the FreeBSD k
On Mon, Jan 20, 2014 at 5:55 PM, Ansis Atteka wrote:
> Without these two iptables rules (one for UDP encapsulated IPsec and
> another for direct IPsec), ovs-vswitchd would incorrectly conclude
> that GRE packet belonged to a plain GRE tunnel instead of IPsec GRE
> tunnel.
>
> Reported-by: Aryan Ta
> +bfd->ip_src = htonl(0xA9FE0100); /* 169.254.1.0. */
> +bfd->ip_dst = htonl(0xA9FE0101); /* 169.254.1.1. */
> +
I don't see a reason to set the defaults here as it will just get set
again later if the IP address fails to parse.
> +
> + Set to an IPv4 address, e.g
On Tue, Jan 21, 2014 at 10:04 AM, Ben Pfaff wrote:
> On Tue, Jan 21, 2014 at 10:02:09AM -0800, Gurucharan Shetty wrote:
>> On Tue, Jan 7, 2014 at 10:31 AM, Ben Pfaff wrote:
>> > On Mon, Jan 06, 2014 at 02:40:34PM -0800, Gurucharan Shetty wrote:
>> >> One option to implement openlog and syslog fun
One option to implement openlog and syslog functionality in windows
is to use windows event logger. But it looks like it involves changing
registry settings and in general looks complicated.
For the time being, do nothing for syslog. All the information needed for
debugging will be present through
On Tue, Jan 21, 2014 at 10:02:09AM -0800, Gurucharan Shetty wrote:
> On Tue, Jan 7, 2014 at 10:31 AM, Ben Pfaff wrote:
> > On Mon, Jan 06, 2014 at 02:40:34PM -0800, Gurucharan Shetty wrote:
> >> One option to implement openlog and syslog functionality in windows
> >> is to use windows event logger
LOG_LOCAL0 is used in lib/vlog.c.
Signed-off-by: Gurucharan Shetty
---
v1->v2:
No change.
---
include/windows/syslog.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/windows/syslog.h b/include/windows/syslog.h
index 484cd10..4a2f38b 100644
--- a/include/windows/syslo
On Tue, Jan 7, 2014 at 10:31 AM, Ben Pfaff wrote:
> On Mon, Jan 06, 2014 at 02:40:34PM -0800, Gurucharan Shetty wrote:
>> One option to implement openlog and syslog functionality in windows
>> is to use windows event logger. But it looks like it involves changing
>> registry settings and in genera
On Tue, Jan 21, 2014 at 09:54:27AM -0800, Jesse Gross wrote:
> On Wed, Jan 15, 2014 at 3:46 PM, Luigi Rizzo wrote:
> > i see. So the const qualifier in the argument to those functions
> > is ignored/overridden intentionally ?
>
> Well really we have two types of functions here: one that accepts a
On Wed, Jan 15, 2014 at 3:46 PM, Luigi Rizzo wrote:
> On Wed, Jan 15, 2014 at 03:10:35PM -0800, Jesse Gross wrote:
>> On Sat, Jan 11, 2014 at 4:33 PM, Luigi Rizzo wrote:
>> > Hi,
>> > in porting the ovs kernel code to the FreeBSD kernel,
>> > compiling with -Wcast-qual -Werror gives some
>> >
>>
Applied, thanks!
On Wed, Jan 08, 2014 at 01:41:38PM -0800, Alex Wang wrote:
> Looks good to me,
>
>
> On Thu, Dec 5, 2013 at 9:29 PM, Ben Pfaff wrote:
>
> > OpenFlow 1.1 through 1.4 say that the out_group in a flow_mod, for commands
> > other than OFPFC_DELETE or OFPFC_DELETE_STRICT, should be
Signed-off-by: Ben Pfaff
---
FAQ | 17 +
1 file changed, 17 insertions(+)
diff --git a/FAQ b/FAQ
index 75d9e6b..dac8fe1 100644
--- a/FAQ
+++ b/FAQ
@@ -1454,6 +1454,23 @@ A: These flows drop the ARP packets that IP hosts use to
establish IP
priority=5,in_port=1,dl_dst=01
On Sun, Jan 19, 2014 at 03:39:24PM -0200, Rafael Duarte Vencioneck wrote:
> I'm interested in implement a new openflow 1.0 vendor extension message.
> Can somebody kindly help me telling what do I have to modify on openvswitch?
> I'm using the 1.9.3 version.
> I would like to document this process
Thanks Ben for your quick reply.
On 21/01/14 9:43 PM, "Ben Pfaff" wrote:
>On Tue, Jan 21, 2014 at 11:40:29AM +0530, Arun Sharma wrote:
>> Thanks for reply. Please find inline comments.
>
>Your responses look reasonable, except that I'm not entirely sure about
>getaddrinfo. I'll take a look at t
On Tue, Jan 21, 2014 at 11:40:29AM +0530, Arun Sharma wrote:
> Thanks for reply. Please find inline comments.
Your responses look reasonable, except that I'm not entirely sure about
getaddrinfo. I'll take a look at that in the new version.
Thanks,
Ben.
__
Cette newsletter vous a été envoyée au format graphique HTML.
Si vous lisez cette version, alors votre logiciel de messagerie préfère les
e-mails au format texte.
Vous pouvez lire la version originale en ligne:
http:/
45 matches
Mail list logo
