Thanks. I pushed this one to master and branch-1.[3456].
I see that Pravin already reviewed it but the second patch can wait
until tomorrow at least.
On Mon, Feb 27, 2012 at 05:28:22PM -0800, Ethan Jackson wrote:
> This looks good to me, I'm not planning to review the second patch of
> the serie
On Mon, Feb 27, 2012 at 06:37:19PM -0800, Ben Pfaff wrote:
> On Tue, Feb 28, 2012 at 10:59:44AM +0900, Simon Horman wrote:
> > On Mon, Feb 27, 2012 at 04:51:45PM -0800, Chris Wright wrote:
> > > * Simon Horman (ho...@verge.net.au) wrote:
> > > > This makes struct nx_set_flow_format consistent with
On Tue, Feb 28, 2012 at 10:59:44AM +0900, Simon Horman wrote:
> On Mon, Feb 27, 2012 at 04:51:45PM -0800, Chris Wright wrote:
> > * Simon Horman (ho...@verge.net.au) wrote:
> > > This makes struct nx_set_flow_format consistent with
> > > other similar structures.
> > >
> > > Signed-off-by: Simon H
On Mon, Feb 27, 2012 at 04:51:45PM -0800, Chris Wright wrote:
> * Simon Horman (ho...@verge.net.au) wrote:
> > This makes struct nx_set_flow_format consistent with
> > other similar structures.
> >
> > Signed-off-by: Simon Horman
>
> Looks good to me.
>
> Acked-by: Chris Wright
>
> BTW, struc
On Mon, Feb 27, 2012 at 5:03 PM, Ben Pfaff wrote:
> When OVS_VPORT_ATTR_NAME is specified and dp_ifindex is nonzero, the
> logical behavior would be for the vport name lookup scope to be limited
> to the specified datapath, but in fact the dp_ifindex value was ignored.
> This commit causes the sea
On Mon, Feb 27, 2012 at 09:39:55AM -0800, Ben Pfaff wrote:
> On Sun, Feb 26, 2012 at 10:31:26AM +0900, Simon Horman wrote:
> > On Sat, Feb 25, 2012 at 12:09:25AM -0800, Ben Pfaff wrote:
> > > On Tue, Feb 21, 2012 at 03:26:38PM +0900, Simon Horman wrote:
> > > > On Wed, Feb 15, 2012 at 04:37:47PM -0
This looks good to me, I'm not planning to review the second patch of
the series.
Ethan
On Mon, Feb 27, 2012 at 17:03, Ben Pfaff wrote:
> The kernel will report a vport with the given name in any datapath, but
> userspace only wants a vport with the given name in a specific datapath.
> Receiving
On Mon, Feb 27, 2012 at 04:51:45PM -0800, Chris Wright wrote:
> * Simon Horman (ho...@verge.net.au) wrote:
> > This makes struct nx_set_flow_format consistent with
> > other similar structures.
> >
> > Signed-off-by: Simon Horman
>
> Looks good to me.
>
> Acked-by: Chris Wright
>
> BTW, struc
When OVS_VPORT_ATTR_NAME is specified and dp_ifindex is nonzero, the
logical behavior would be for the vport name lookup scope to be limited
to the specified datapath, but in fact the dp_ifindex value was ignored.
This commit causes the search scope to be honored.
Signed-off-by: Ben Pfaff
---
da
The kernel will report a vport with the given name in any datapath, but
userspace only wants a vport with the given name in a specific datapath.
Receiving information on a vport in an unexpected datapath yields bizarre
and hard-to-debug problems.
Signed-off-by: Ben Pfaff
---
lib/dpif-linux.c |
These two patches are alternative fixes to a bug that can arise when a
single database transaction moves one or more ports from one bridge
to another and there is an overlap between the port numbers that the
ports had on their previous bridge and the port numbers of existing
ports on the destinatio
* Simon Horman (ho...@verge.net.au) wrote:
> This makes struct nx_set_flow_format consistent with
> other similar structures.
>
> Signed-off-by: Simon Horman
Looks good to me.
Acked-by: Chris Wright
BTW, struct nx_flow_mod_table_id vendor/subtype would default to arch-Endian,
(which seems lik
This makes struct nx_set_flow_format consistent with
other similar structures.
Signed-off-by: Simon Horman
---
include/openflow/nicira-ext.h |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/include/openflow/nicira-ext.h b/include/openflow/nicira-ext.h
index 042d304..ae
On Fri, Feb 17, 2012 at 03:41:52PM -0800, Gurucharan Shetty wrote:
> For self-signed certificates, increase validity from the default
> 30 days to 6 years.
>
> Signed-off-by: Gurucharan Shetty
This patch looks good to me. I think that we should commit this patch
regardless of 2/3 and 3/3.
Than
Thanks, I've merged this series.
Ethan
On Mon, Feb 27, 2012 at 15:14, Ben Pfaff wrote:
> On Mon, Feb 20, 2012 at 11:42:15PM -0800, Ethan Jackson wrote:
>> Here's an incremental.
>
> Looks good, thank you.
___
dev mailing list
dev@openvswitch.org
http:/
On Mon, Feb 20, 2012 at 11:42:15PM -0800, Ethan Jackson wrote:
> Here's an incremental.
Looks good, thank you.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Here's an incremental.
---
lib/unixctl.c | 76 +--
lib/vlog.c |2 +-
utilities/ovs-appctl.c |3 +-
3 files changed, 36 insertions(+), 45 deletions(-)
diff --git a/lib/unixctl.c b/lib/unixctl.c
index c68b059..054ce49 10064
> I was suggesting an optional simplification. Obviously when I wrote
> the existing code I had the idea of back-to-back requests in mind, or
> I wouldn't have written it that way. But the only existing client
> only sends a single request per program execution, so multiple
> back-to-back request
On Mon, Feb 27, 2012 at 02:52:37PM -0800, Ethan Jackson wrote:
> > I don't think you need to kill the connection object immediately.
> > Errors are "sticky", that is, the next call to jsonrpc_get_status()
> > will report the same error, so you can let run_connection() in the
> > call to unixctl_ser
On Mon, Feb 27, 2012 at 02:04:54PM -0800, Ethan Jackson wrote:
> > I would argue that run_connection() should only read a new request
> > if the connection is not backlogged (this is already tested in
> > unixctl_server_wait() so maybe that was your intention all along?).
> >
> > I don't think that
> I don't think you need to kill the connection object immediately.
> Errors are "sticky", that is, the next call to jsonrpc_get_status()
> will report the same error, so you can let run_connection() in the
> call to unixctl_server_run() destroy the connection object.
Yeah you're right, I realized
On Mon, Feb 27, 2012 at 01:35:04PM -0800, Ethan Jackson wrote:
> > My thinking was that once I've sent the request, I need to destroy the
> > 'conn' object. and now the caller has this dangling reference.
> > However, the more I think about it, the less valid this argument is
> > because I already
> I would argue that run_connection() should only read a new request
> if the connection is not backlogged (this is already tested in
> unixctl_server_wait() so maybe that was your intention all along?).
>
> I don't think that run_connection() really needs a loop. One try
> should be enough. (I t
> My thinking was that once I've sent the request, I need to destroy the
> 'conn' object. and now the caller has this dangling reference.
> However, the more I think about it, the less valid this argument is
> because I already make assertions preventing a caller from making a
> reply twice. Perha
> In enable_slave() in lib/bond.c, I think that the following is
> actually a bug fix. If so, can you separate out the bug fix from the
> wholesale conversion, so that we can commit it to old release
> branches?
>
> bond_enable_slave(slave, enable, &bond->unixctl_tags);
> - unixctl_command
[adding ovs-dev back]
Oops. And in fact it was even committed. I'm forgetful. Thanks.
On Mon, Feb 27, 2012 at 12:54:12PM -0800, Ethan Jackson wrote:
> It looks to me like Justin already reviewed this.
>
> Ethan
>
> On Mon, Feb 27, 2012 at 09:32, Ben Pfaff wrote:
> > On Fri, Feb 10, 2012 at
On Mon, Feb 27, 2012 at 01:06:19PM -0800, Ethan Jackson wrote:
> > Yes, it is odd. I chose to do it that way in case, in the future, we
> > decide that we need longer controller IDs. If we do that, then we can
> > keep using the same struct here, just changing the ovs_be16 to an
> > ovs_be32 or o
The bond/enable-slave and bond/disable-slave ovs-appctl commands
incorrectly reported the 501 error code upon success.
Signed-off-by: Ethan Jackson
---
lib/bond.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/bond.c b/lib/bond.c
index 157e988..1ad2367 100644
--- a
On Thu, Feb 16, 2012 at 04:57:17PM -0800, Ethan Jackson wrote:
> The unixctl library had used the vde2 management protocol since the
> early days of Open vSwitch. As Open vSwitch has matured, several
> Python daemons have been added to the code base which would benefit
> from a unixctl implementat
> Yes, it is odd. I chose to do it that way in case, in the future, we
> decide that we need longer controller IDs. If we do that, then we can
> keep using the same struct here, just changing the ovs_be16 to an
> ovs_be32 or ovs_be64. Admittedly it's strange, but I didn't see a
> reason that it
> Will you backport this?
Summary of an offline discussion:
I don't think the change needs to be backported because nothing in the
code base uses jsonrpc to return a message in the 'error' field.
Therefore it's not possible to hit the bug. The next patch in the
series uses this functionality, so
On Thu, Feb 16, 2012 at 04:57:16PM -0800, Ethan Jackson wrote:
> If a server returned an error in response to a request,
> jsonrpc_transact_block() would ignore it. This patch changes the
> behavior and updates its callers to gracefully handle the
> possibility.
>
> Signed-off-by: Ethan Jackson
There's no reason for a Unix domain client socket to bind a name. I don't
know why we've always done that. Stevens's "Unix Network Programming"
Unix domain socket client example doesn't do a bind.
Removes the 'unlink_path' parameter from new_fd_stream() since it is now
always passed as NULL.
Si
The error handling path here failed to clean up bound sockets, by removing
them. This fixes the problem.
It was easy to observe this bug by running "ovs-vsctl" without
"ovsdb-server" running.
Bug #9769.
Reported-by: Michael
Signed-off-by: Ben Pfaff
---
lib/socket-util.c |4 ++--
1 files c
Thanks, I've merged this.
Ethan
On Mon, Feb 27, 2012 at 09:49, Ben Pfaff wrote:
> On Sat, Feb 18, 2012 at 07:29:15PM -0800, Ethan Jackson wrote:
>> I would have found this information useful when debugging a problem
>> recently.
>>
>> Signed-off-by: Ethan Jackson
>
> Looks good, thank you.
On Fri, Feb 24, 2012 at 08:06:21AM +0900, Simon Horman wrote:
> Make the string parameter of parse_ofp_flow_stats_request_str() and
> parse_ofp_flow_mod_str() const
>
> * Both parse_ofp_flow_stats_request_str() and parse_ofp_flow_mod_str()
> only pass their string parameter to it to parse_ofp_st
Hi,
If I understand test-flows utility correctly it tries to match the packets from
pcap to a flow. Currently I am facing some issue where I have generated pcap
file via tcpdump -nnevvvXSw -i br0. It contains around 32 captured packets.
When I run test-flow with the pcap and flow-install files
On Thu, Feb 23, 2012 at 05:58:07PM -0800, Ethan Jackson wrote:
> This looks good to me.
Thanks, I'll push it in a moment.
> > + * Copyright (c) 2008, 2009, 2010, 2011, 2012 Nicira Networks.
>
> Completely unrelated to this patch, these things are starting to get
> fairly long. I wonder if it ma
On Thu, Feb 23, 2012 at 10:55:43PM +0900, Simon Horman wrote:
> Signed-off-by: Simon Horman
Pushed, thank you.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, Feb 22, 2012 at 02:49:09PM -0800, Ethan Jackson wrote:
> > +/* Destroys 'rpc', closing the stream on which it is based, and frees its
> > + * memory. !*/
>
> This exclamation point is redundant.
Redundant? Well, mistaken away. I removed it.
> Otherwise looks good, thanks for documentin
Thanks, I pushed this.
On Wed, Feb 22, 2012 at 02:36:32PM -0800, Ethan Jackson wrote:
> Looks good,
>
> Ethan
>
> On Tue, Feb 21, 2012 at 09:30, Ben Pfaff wrote:
> > At one time (before facets were called facets), the existence of a facet
> > implied that its parent rule was not idle. This is
On Sat, Feb 18, 2012 at 07:29:15PM -0800, Ethan Jackson wrote:
> I would have found this information useful when debugging a problem
> recently.
>
> Signed-off-by: Ethan Jackson
Looks good, thank you.
___
dev mailing list
dev@openvswitch.org
http://ope
On Sun, Feb 26, 2012 at 10:31:26AM +0900, Simon Horman wrote:
> On Sat, Feb 25, 2012 at 12:09:25AM -0800, Ben Pfaff wrote:
> > On Tue, Feb 21, 2012 at 03:26:38PM +0900, Simon Horman wrote:
> > > On Wed, Feb 15, 2012 at 04:37:47PM -0800, Ben Pfaff wrote:
> > > > The intention is that, as each OpenFl
On Sun, Feb 26, 2012 at 10:34:08AM +0900, Simon Horman wrote:
> On Sat, Feb 25, 2012 at 12:11:20AM -0800, Ben Pfaff wrote:
> > On Tue, Feb 21, 2012 at 03:53:48PM +0900, Simon Horman wrote:
> > > On Wed, Feb 15, 2012 at 04:37:43PM -0800, Ben Pfaff wrote:
> > > > This comprises most of the previously
On Wed, Feb 22, 2012 at 02:23:38PM -0800, Ethan Jackson wrote:
> Looks good to me.
Thanks, I pushed it.
> I wonder if it makes sense or is possible to generalize this and use
> it to print vlog debug messages in rtnetlink-link. We don't have a
> precedent for logging in that file so maybe it isn
On Fri, Feb 10, 2012 at 11:00:54AM -0800, Ben Pfaff wrote:
> The OVS kernel module, like other kernel modules, does not need a working
> userspace build environment, but the OVS "configure" script and makefiles
> don't support a kernel-only build, so "configure" fails if libc6-dev is
> not installe
Thank you, I pushed this.
On Wed, Feb 22, 2012 at 01:50:59PM -0800, Ethan Jackson wrote:
> Looks good,
>
> Ethan
>
> On Tue, Feb 7, 2012 at 16:17, Ben Pfaff wrote:
> > Suggestion #9347.
> > Suggested-by: Alan Shieh
> > Signed-off-by: Ben Pfaff
> > ---
> > This builds on the async-msgs series
On Fri, Feb 24, 2012 at 01:01:38PM -0800, Ethan Jackson wrote:
> There's some trailing whitespace in one of the man pages.
>
> > %if %{?kernel_name:0}%{!?kernel_name:1}
> > -%define kernel %(rpm -qa 'kernel*xen-devel')
> > +%define kernel %(rpm -qa 'kernel*xen-devel' | head -1)
> > %define kerne
On Tue, Feb 21, 2012 at 06:16:36PM -0800, Ethan Jackson wrote:
> nicira-ext.h:
> I'm surprised the zero padding is put before the 'controller_id' field
> in struct nx_controller_id. Typically we've done it the other way
> around, though I don't think it matters in particular. Was there a
> specif
49 matches
Mail list logo
