On Wed, Sep 11, 2013 at 07:01:27PM -0700, Ethan Jackson wrote:
> My main high level concern about this patch is that we've ditched the
> thread safety annotations from struct rule_dpif. I think they're
> still useful even if the rule isn't literally locked. Semantically we
> say struct rule_dpif
On Wed, Sep 11, 2013 at 06:51:11PM -0700, Ethan Jackson wrote:
> My only comment is that you might consider using thread safety
> annotations to force users do un-reference actions they've taken a
> reference of. That might be a pain though, not sure if it's worth it.
Thread-safety annotations ma
On Thu, Sep 12, 2013 at 12:56:53AM +0300, Daniel Baluta wrote:
> This is a first step in implementing 'on demand flow counters'.
>
> We save relevant flow_mod flags (OFPUTIL_FF_SEND_FLOW_REM,
> OFPUTIL_FF_NO_PKT_COUNTS, OFPUTIL_FF_NO_BYT_COUNTS) into newly created rule
> when a new flow is added,
Thanks, applied.
On Wed, Sep 11, 2013 at 11:11:17AM -0700, Jarno Rajahalme wrote:
> Acked-by: Jarno Rajahalme
>
> On Sep 11, 2013, at 10:02 AM, Ben Pfaff wrote:
>
> > Reported-by: Aws Auger
> > Signed-off-by: Ben Pfaff
> > ---
> > FAQ | 50 ++
On Mon, Sep 09, 2013 at 06:05:43PM -0700, Paul Ingram wrote:
> The ovsdb-server compaction timing logic is written assuming milliscond
> resolution timestamps but ovsdb-server wrote second resolution timestamps.
>
> This commit changes ovsdb-server to write millisecond resolution timestamps
> and
On Mon, Sep 09, 2013 at 06:05:42PM -0700, Paul Ingram wrote:
> To make debugging easier.
It's reasonable enough.
I didn't really like the %. format specification for this. It is
inflexible--what if someone wants only tenths of a second or wants
microseconds? It is also somewhat hard to parse si
On Mon, Sep 09, 2013 at 10:20:37AM -0700, gy...@nicira.com wrote:
> From: Guolin Yang
>
> There are two models in OVS in configure datapath port:
> 1. Datapath port created before user space bridge is configured.
>In this model, datapath can be deleted or added independent of
>user-space.
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> I think that ->timeout_mutex and ->mutex were separate because the latter
> (which was actually a rwlock named ->rwlock until recently) was held for
> long periods of time, which meant that having a separate ->timeout_
This patch removes a ovs_mutex_destroy(&ofproto_mutex) call from
ofproto_destroy__() perhaps a rebasing error?
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> A rwlock is suitable when one expects long hold times so there is a need
> for some parallelism for reade
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> The cookie index is only used for flow_mods, so it makes sense to use this
> global mutex.
>
> Signed-off-by: Ben Pfaff
> ---
> ofproto/ofproto-provider.h |5 +++--
> ofproto/ofproto.c | 15 +++
I posted this review on the wrong patch, but here it is on the right one:
FWIW I think this is the right choice given the options. May be worth
adding a comment in the actual code as to why we can't just execute
the rule and have to queue it instead.
Acked-by: Ethan Jackson
On Tue, Sep 10, 201
Oops I intended that review for the previous patch. This patch is
fine too though.
Acked-by: Ethan Jackson
On Wed, Sep 11, 2013 at 7:12 PM, Ethan Jackson wrote:
> FWIW I think this is the right choice given the options. May be worth
> adding a comment in the actual code as to why we can't j
FWIW I think this is the right choice given the options. May be worth
adding a comment in the actual code as to why we can't just execute
the rule and have to queue it instead.
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> This is the first step toward making a
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff
> ---
> lib/classifier.c |3 ++-
> lib/classifier.h |2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib/classifier.c b/lib/classifier.c
> index 93ee977..36e
Looks good we've needed this badly. Any reason not to update the
drop_keys, upcalls, and fmbs lists in ofproto-dpif-upcall as well? May
need a couple more helpers, but this seems right up their ally.
May be worth poisoning the list in guarded_list_destroy().
Acked-by: Ethan Jackson
On Tue, Se
My main high level concern about this patch is that we've ditched the
thread safety annotations from struct rule_dpif. I think they're
still useful even if the rule isn't literally locked. Semantically we
say struct rule_dpif is lockable, rule_dpif_ref() takes a shared lock
on it, and rule_dpif_u
My only comment is that you might consider using thread safety
annotations to force users do un-reference actions they've taken a
reference of. That might be a pain though, not sure if it's worth it.
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> This permits cod
This commit makes vswitchd clear the 'bfd_status' column
in ovsdb when bfd is disabled.
Reported-by: Ansis Atteka
Signed-off-by: Alex Wang
---
vswitchd/bridge.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 5e54e0b..f4929
This commit fixes a place in bridge.c where smap_destroy() is not
always called after smap_init(). Though there is no memory leak
now, it is necessary to fix it and prevent memory leak in the
future when smap_init() may be modified to allocate dynamic memory.
Reported-by: Ansis Atteka
Signed-off
I see, I'll resend v2 patch. Thanks,
On Wed, Sep 11, 2013 at 5:06 PM, Ben Pfaff wrote:
> On Wed, Sep 11, 2013 at 04:39:40PM -0700, Alex Wang wrote:
> > This commit makes ovsdb clear the 'bfd_status' column
> > when bfd is disabled.
> >
> > Reported-by: Ansis Atteka
> > Signed-off-by: Alex Wang
On Wed, Sep 11, 2013 at 04:39:40PM -0700, Alex Wang wrote:
> This commit makes ovsdb clear the 'bfd_status' column
> when bfd is disabled.
>
> Reported-by: Ansis Atteka
> Signed-off-by: Alex Wang
The Subject should refer to "vswitchd:", since this is vswitchd
code. ("ovsdb:" would be for chang
Thanks Ansis,
I'll send a separate patch for that.
On Wed, Sep 11, 2013 at 5:02 PM, Ansis Atteka wrote:
> This looks reasonable to me. One comment above.
>
> On Wed, Sep 11, 2013 at 4:39 PM, Alex Wang wrote:
> > This commit makes ovsdb clear the 'bfd_status' column
> > when bfd is disabled.
>
This looks reasonable to me. One comment above.
On Wed, Sep 11, 2013 at 4:39 PM, Alex Wang wrote:
> This commit makes ovsdb clear the 'bfd_status' column
> when bfd is disabled.
>
> Reported-by: Ansis Atteka
> Signed-off-by: Alex Wang
> ---
> vswitchd/bridge.c |5 +++--
> 1 file changed, 3
This commit makes ovsdb clear the 'bfd_status' column
when bfd is disabled.
Reported-by: Ansis Atteka
Signed-off-by: Alex Wang
---
vswitchd/bridge.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 5e54e0b..f49292b 100644
--
This is a first step in implementing 'on demand flow counters'.
We save relevant flow_mod flags (OFPUTIL_FF_SEND_FLOW_REM,
OFPUTIL_FF_NO_PKT_COUNTS, OFPUTIL_FF_NO_BYT_COUNTS) into newly created rule
when a new flow is added, and echo them back in the flow stats request.
Notice that we remove send
On Wed, Sep 11, 2013 at 01:20:19PM -0700, Ethan Jackson wrote:
> In ofproto_add_flow(). If the rule already exists and you re-add it,
> are you supposed to tweak any state about it? I.E. update it's
> created time or something?
Yes, one must do this for flow table modifications that come in via
On Wed, Sep 11, 2013 at 01:10:50PM -0700, Ethan Jackson wrote:
> In rule_expire() can we be can we trust the rule->up.pending
> assertion on alternate ofproto providers? I'm not sure if alternate
> ofproto providers actually exist so it may not matter. Perhaps we
> should ditch rule->up.pending e
On Wed, Sep 11, 2013 at 01:07:11PM -0700, Ethan Jackson wrote:
> You've got two signed-off-bys.
Oops. Thanks, I've now fixed that up.
> Acked-by: Ethan Jackson
>
>
> On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> > Signed-off-by: Ben Pfaff
> >
> > Signed-off-by: Ben Pfaff
> > ---
> >
Ingresá a www.abseguro.com y cotizá todas las aseguradoras en un solo lugar. Ahorrá hasta un 35% en el seguro de tu auto!
más atención
más beneficios
...mucho más que un seguro.___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/list
On Sep 11, 2013, at 1:14 PM, Ethan Jackson wrote:
> A set of ofpacts can only have one meter? What an odd API . . . At
> any rate this is fine.
Each flow entry can have only one instruction of each type associated with it.
The meter instruction, if it exists, must be executed first. Therefore
You've got two signed-off-bys.
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff
>
> Signed-off-by: Ben Pfaff
> ---
> ofproto/ofproto.c |5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/ofproto/ofproto.c b/of
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff
> ---
> ofproto/ofproto.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
> index 388463a..b027873 100644
> --- a/ofproto/o
I'm not sure collect_rule() is a great name for the function, but on
the other hand I'm not sure what I'd call it either. At any rate I
like how much duplicate code this removes.
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff
> ---
> of
In ofproto_add_flow(). If the rule already exists and you re-add it,
are you supposed to tweak any state about it? I.E. update it's
created time or something?
Patch looks nice thanks.
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> Until now, ofproto_add_flow()
A set of ofpacts can only have one meter? What an odd API . . . At
any rate this is fine.
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> ofproto is too big anyway so we might as well move out code that can
> reasonably live elsewhere.
>
> Signed-off-by: Ben Pfaff
In rule_expire() can we be can we trust the rule->up.pending assertion
on alternate ofproto providers? I'm not sure if alternate ofproto
providers actually exist so it may not matter. Perhaps we should
ditch rule->up.pending entirely?
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, B
Acked-by: Ethan Jackson
On Tue, Sep 10, 2013 at 10:27 PM, Ben Pfaff wrote:
> These functions were identical but had different names (one just called
> the other). Make them a single function.
>
> Signed-off-by: Ben Pfaff
> ---
> ofproto/ofproto.c | 35 +++
>
From: Jesse Gross
Date: Sat, 7 Sep 2013 22:35:33 -0700
> On Sat, Sep 7, 2013 at 12:41 AM, Daniel Borkmann wrote:
>> In function __parse_flow_nlattrs(), we check for condition
>> (type > OVS_KEY_ATTR_MAX) and if true, print an error, but we do
>> not return from this function as in other checks.
Thanks, applied as follows (at end).
On Wed, Sep 11, 2013 at 11:47:49AM -0700, Andy Zhou wrote:
> This looks good to me.
>
>
> On Wed, Sep 11, 2013 at 10:28 AM, Ben Pfaff wrote:
>
> > On Tue, Sep 10, 2013 at 01:33:08PM -0700, Andy Zhou wrote:
> > > OFPTC11_TABLE_MISS_MASK is not a valid config
Thanks Simon for your input. I think we are on the same page now.
I have sent out a patch to address this yesterday. Please feel free to
review it.
On Tue, Sep 10, 2013 at 8:57 PM, Simon Horman wrote:
> On Tue, Sep 10, 2013 at 09:17:10AM -0700, Andy Zhou wrote:
> > I don't think OFPTC11_TABLE_
This looks good to me.
On Wed, Sep 11, 2013 at 10:28 AM, Ben Pfaff wrote:
> On Tue, Sep 10, 2013 at 01:33:08PM -0700, Andy Zhou wrote:
> > OFPTC11_TABLE_MISS_MASK is not a valid configuration, but to indicate
> > there are only 2 bits being used for table miss configuration. Move
> > it out of
Acked-by: Jarno Rajahalme
On Sep 11, 2013, at 10:02 AM, Ben Pfaff wrote:
> Reported-by: Aws Auger
> Signed-off-by: Ben Pfaff
> ---
> FAQ | 50 ++
> 1 file changed, 50 insertions(+)
>
> diff --git a/FAQ b/FAQ
> index 7181484..20a3e3b 100644
> -
On Tue, Sep 10, 2013 at 01:33:08PM -0700, Andy Zhou wrote:
> OFPTC11_TABLE_MISS_MASK is not a valid configuration, but to indicate
> there are only 2 bits being used for table miss configuration. Move
> it out of the enum definition.
>
> Reported-by: Simon Horman
> Signed-off-by: Andy Zhou
I ag
On Wed, Sep 11, 2013 at 02:19:02PM +0200, Martino Fornasa wrote:
> Ben Pfaff wrote:
> >On Tue, Sep 10, 2013 at 05:34:28PM +0200, Martino Fornasa wrote:
> >>Ben Pfaff wrote:
> >>>On Tue, Sep 10, 2013 at 03:26:48PM +0200, Martino Fornasa wrote:
> >>>This sounds very nice. Do you plan to make the resu
Reported-by: Aws Auger
Signed-off-by: Ben Pfaff
---
FAQ | 50 ++
1 file changed, 50 insertions(+)
diff --git a/FAQ b/FAQ
index 7181484..20a3e3b 100644
--- a/FAQ
+++ b/FAQ
@@ -1249,6 +1249,56 @@ A: An empty set of actions causes a packet to be
d
On Wed, Sep 11, 2013 at 06:41:40PM +0500, Junaid Rao wrote:
> I have developed a custom netdev provider and running OVS-1.10.0 in
> userspace mode. it works fine but the packet processing rate is quite slow.
> Packet transmission rate is about 500packets/sec but OVS is only able to
> forward 1/5th
Reported-by: Torbjorn Tornkvist
Signed-off-by: Ben Pfaff
---
OPENFLOW-1.1+ |5 +
1 file changed, 5 insertions(+)
diff --git a/OPENFLOW-1.1+ b/OPENFLOW-1.1+
index 7a75c44..f579e12 100644
--- a/OPENFLOW-1.1+
+++ b/OPENFLOW-1.1+
@@ -106,6 +106,11 @@ additional work specific to Openflow 1.2
I have found out it was not the issue with release, it is hardware specific
problem and I am investigating it more.
Thanks for your response.
On Thu, Sep 5, 2013 at 11:03 PM, Justin Pettit wrote:
> Sorry, I haven't put it up on the site yet. I'll do it in the next couple
> of hours.
>
> --Just
Hello,
I have developed a custom netdev provider and running OVS-1.10.0 in
userspace mode. it works fine but the packet processing rate is quite slow.
Packet transmission rate is about 500packets/sec but OVS is only able to
forward 1/5th of this.
The arrival of incoming packet at the switch is in
Ben Pfaff wrote:
On Tue, Sep 10, 2013 at 05:34:28PM +0200, Martino Fornasa wrote:
Ben Pfaff wrote:
On Tue, Sep 10, 2013 at 03:26:48PM +0200, Martino Fornasa wrote:
This sounds very nice. Do you plan to make the result available to
the Open vSwitch community?
We do, as soon as we reach a decent
On 3 September 2013 22:53, Jesse Gross wrote:
> Thanks, that's what I was looking for. Would you mind submitting the
> patch formally then? (I don't think you need to escape the semicolon
> though.)
Sorry was away on vacations..
Yeah, I will resubmit it then.. I kept semicolon as well to make it
51 matches
Mail list logo
