On Mon, Mar 19, 2012 at 06:02:32PM -0700, Ethan Jackson wrote:
> This prevents potential race conditions when updating database
> tables.
>
> Signed-off-by: Ethan Jackson
Looks good, thank you.
___
dev mailing list
dev@openvswitch.org
http://openvswitc
Please see inline
On Mon, Mar 19, 2012 at 2:14 PM, wrote:
> When kernel >= 2.6.37 and vlan_tpid = 0x88a8, in function netdev_send,
> __vlan_put_tag present in OVS tree is not executed since
> dev_supports_vlan_tx returns true. It goes through the path of
> dev_queue_xmit which eventually calls
On Tue, Mar 20, 2012 at 11:43:38AM +0900, Simon Horman wrote:
> On Mon, Mar 19, 2012 at 02:31:36PM -0700, Ben Pfaff wrote:
> > On Mon, Mar 19, 2012 at 09:54:43AM +0900, Simon Horman wrote:
> > > Signed-off-by: Simon Horman
> >
> > This looks good to me with a few comments.
> >
> > The meanings o
Looks good to me.
Unrelated to this patch, we've still got some inconsistencies about the range
of VLANs supported. For example, mirroring and CFM don't allow configuring an
output VLAN of zero. Should we look into adding that?
--Justin
On Mar 16, 2012, at 1:13 PM, Ben Pfaff wrote:
> A fak
> Unrelated to this patch, we've still got some inconsistencies about the range
> of VLANs supported. For example, mirroring and CFM don't allow configuring
> an output VLAN of zero. Should we look into adding that?
The CFM code assumes that having a zero vlan and no vlan tag are
equivalent.
On Tue, Mar 20, 2012 at 10:19 AM, wrote:
> Please see inline
>
> On Mon, Mar 19, 2012 at 2:14 PM, wrote:
>> When kernel >= 2.6.37 and vlan_tpid = 0x88a8, in function netdev_send,
>> __vlan_put_tag present in OVS tree is not executed since
>> dev_supports_vlan_tx returns true. It goes through t
On Tue, Mar 20, 2012 at 11:01 AM, Justin Pettit wrote:
> Looks good to me.
>
> Unrelated to this patch, we've still got some inconsistencies about the range
> of VLANs supported. For example, mirroring and CFM don't allow configuring
> an output VLAN of zero. Should we look into adding that?
Hi,
I missed that one email, just saw it when reviewing the bug.
On Fri, Mar 09, 2012 at 12:06:03AM +0800, Thomas Goirand wrote:
>>> E: openvswitch-datapath-dkms: python-script-but-no-python-dep
usr/src/openvswitch-1.4.0/build-aux/check-structs
[ ... many of the same ...]
Ben Pfaff wrote:
> The
Inline
-Original Message-
From: dev-boun...@openvswitch.org [mailto:dev-boun...@openvswitch.org] On
Behalf Of Jesse Gross
Sent: Tuesday, March 20, 2012 11:33 AM
To: Kerur, Ravi
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev] mpls and vlan qinq
On Tue, Mar 20, 2012 at 10:19 AM, wrote:
>
On Tue, Mar 20, 2012 at 2:45 PM, wrote:
> Inline
>
> -Original Message-
> From: dev-boun...@openvswitch.org [mailto:dev-boun...@openvswitch.org] On
> Behalf Of Jesse Gross
> Sent: Tuesday, March 20, 2012 11:33 AM
> To: Kerur, Ravi
> Cc: dev@openvswitch.org
> Subject: Re: [ovs-dev] mpls
The first couple of patches fix trivia but the last two are fairly
important.
Ben Pfaff (5):
learn: Initialize cookie_mask in constructed flow_mod.
ofproto-dpif: Fix return type of rule_calculate_tag().
hmap: New function hmap_contains().
ofproto-dpif: Avoid segfault deleting facets that e
Otherwise the "learn" action may not correctly set the cookie in flows that
it creates.
Found by valgrind.
Signed-off-by: Ben Pfaff
---
lib/learn.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lib/learn.c b/lib/learn.c
index 9ca8b65..94fc1b0 100644
--- a/lib/learn.c
tag_type is currently uint32_t but using uint32_t directly is conceptually
wrong.
---
ofproto/ofproto-dpif.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 642e3b0..200846b 100644
--- a/ofproto/ofproto-dpif.c
+++ b/
This is useful in a situation where one knows that an hmap_node is in some
hmap, but it's not certain which one, and one needs to know whether it is
in a particular one. This is not a very common case; I don't see any
potential users in the current tree, although an upcoming commit will add
one.
"ovs-ofctl del-flows " can result in the following call path:
delete_flows_loose() in ofproto.c
-> collect_rules_loose() -- uses 'ofproto_node' inside 'struct rule'
-> rule_destruct() in ofproto-dpif.c
-> facet_revalidate()
-> facet_remove()
-> facet_flush_stats()
This code in xlate_table_action() is supposed to tag flows in tables that
have special forms so that changes do not require revalidating every flow.
When rule->tag is nonzero, its value can be used, because we know in this
case that rule->cr.wc is the same as table->other_table->wc and that thus
ru
Looks good, thanks.
Ethan
On Tue, Mar 20, 2012 at 15:44, Ben Pfaff wrote:
> Otherwise the "learn" action may not correctly set the cookie in flows that
> it creates.
>
> Found by valgrind.
>
> Signed-off-by: Ben Pfaff
> ---
> lib/learn.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletion
Looks good.
Ethan
On Tue, Mar 20, 2012 at 15:44, Ben Pfaff wrote:
> tag_type is currently uint32_t but using uint32_t directly is conceptually
> wrong.
> ---
> ofproto/ofproto-dpif.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ofproto/ofproto-dpif.c b/ofprot
Looks good.
Ethan
On Tue, Mar 20, 2012 at 15:44, Ben Pfaff wrote:
> This is useful in a situation where one knows that an hmap_node is in some
> hmap, but it's not certain which one, and one needs to know whether it is
> in a particular one. This is not a very common case; I don't see any
> pot
On Tue, Mar 20, 2012 at 11:01:11AM -0700, Justin Pettit wrote:
> Looks good to me.
Thanks, I pushed this to master and branch-1.[456].
> Unrelated to this patch, we've still got some inconsistencies about
> the range of VLANs supported. For example, mirroring and CFM don't
> allow configuring an
It seems odd to me that we call it 'may_add_flows' in facet_account,
and 'do_learn_action' in action_xlate_ctx. I'd be inclined to call
both of them the same thing. It strikes me, that an appropriate name
for the flag may be "may_flow_mod" as that's the behavior we actually
care about. If we add
Looks good, thanks.
Ethan
On Tue, Mar 20, 2012 at 15:44, Ben Pfaff wrote:
> This code in xlate_table_action() is supposed to tag flows in tables that
> have special forms so that changes do not require revalidating every flow.
> When rule->tag is nonzero, its value can be used, because we know i
Signed-off-by: Ethan Jackson
---
vswitchd/bridge.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 6449333..98f67b6 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -1260,7 +1260,8 @@ bridge_configure_flow_evicti
This removes some boilerplate from the bridge.
Signed-off-by: Ethan Jackson
---
ovsdb/ovsdb-idlc.in | 40 ++
vswitchd/bridge.c | 208 +--
2 files changed, 144 insertions(+), 104 deletions(-)
diff --git a/ovsdb/ovsdb-idlc.in b/ovsdb/ov
>
> +# String Map Helpers.
> +for columnName, column in sorted(table.columns.iteritems()):
> +if not is_string_map(column):
> +continue
> +
> +print
> +print "const char *"
> +print "%(s)s_get_%(c)s_value(const struct %
On Tue, Mar 20, 2012 at 06:27:30PM -0700, Ethan Jackson wrote:
> Signed-off-by: Ethan Jackson
Fine by me!
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, Mar 21, 2012 at 02:59:01AM +0800, Thomas Goirand wrote:
> I missed that one email, just saw it when reviewing the bug.
>
> On Fri, Mar 09, 2012 at 12:06:03AM +0800, Thomas Goirand wrote:
> >>> E: openvswitch-datapath-dkms: python-script-but-no-python-dep
> usr/src/openvswitch-1.4.0/build-a
[resending to address that doesn't bounce for me with SPF complaint]
On Tue, Mar 20, 2012 at 10:25:39PM -0700, Ben Pfaff wrote:
> On Wed, Mar 21, 2012 at 02:59:01AM +0800, Thomas Goirand wrote:
> > I missed that one email, just saw it when reviewing the bug.
> >
> > On Fri, Mar 09, 2012 at 12:06:
28 matches
Mail list logo
