It actually does fix a bug because when the value is zero we don't
serialize the attributes for the value or mask. This is OK for the
value because zero is the default. However, just because the value is
zero doesn't mean that the mask can be omitted (and therefore
wildcarded).
Longer term, the go
Signed-off-by: Ethan Jackson
---
lib/classifier.c|3 +++
lib/classifier.h| 55 +++
ofproto/ofproto-dpif.c | 18 +++-
ofproto/ofproto.c | 43 +++-
tests/test-classifier.c | 19
This patch makes packet_ins thread safe by handing responsibility for
them to ofproto-dpif.
Signed-off-by: Ethan Jackson
---
lib/ofp-util.h |2 ++
ofproto/ofproto-dpif-xlate.c | 21 ---
ofproto/ofproto-dpif.c | 60 +++---
It's simple to hide it than to make it thread safe and ensure it stays
that way in the long term.
Signed-off-by: Ethan Jackson
---
ofproto/ofproto-dpif-xlate.c | 26 +-
ofproto/ofproto-dpif-xlate.h | 12 +++-
ofproto/ofproto-dpif.c |7 +--
ofprot
ofproto_receive() is a slightly odd function which doesn't fit
perfectly in either ofproto-dpif or ofproto-dpif-xlate. However, it's
much easier to reason about its thread safety in ofproto-dpif-xlate,
so this patch moves it there and renames it xlate_receive().
Signed-off-by: Ethan Jackson
---
This patch allows the lookup functions to take NULL as an argument as
a convenience.
Signed-off-by: Ethan Jackson
---
ofproto/ofproto-dpif-xlate.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xla
Signed-off-by: Ethan Jackson
---
ofproto/ofproto-dpif.c | 69 +++-
1 file changed, 51 insertions(+), 18 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 17bc12f..e2dcd3f 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto
Signed-off-by: Ethan Jackson
---
ofproto/ofproto-dpif.c | 13 +++--
ofproto/ofproto-dpif.h |6 --
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 1d3f4ca..439adf7 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofpr
This allows us to move some minor functionality from ofproto-dpif to
ofproto-dpif-xlate, where it's easier to ensure it's thread safe.
Signed-off-by: Ethan Jackson
---
ofproto/ofproto-dpif-xlate.c | 25 ++---
ofproto/ofproto-dpif-xlate.h | 10 ++
ofproto/ofproto-d
Ben,
Here is the procedure I followed.
1. Created bridge --- ovs-vsctl add-br br-int
2. Add port --- ovs-vsctl add-port br-int port1
thats it. ovs-vsctl is not giving any error. when i execute ovs-vsctl
show.
I can see port.
But when I executed ovs-ofctl dump-ports br-int. I saw
Just for completeness, We are dealing with eth_type and in_port by forcing
exact match int the kernel.
On Sat, Aug 3, 2013 at 2:57 PM, Andy Zhou wrote:
> Jesse, please feel free to correct me if I am wrong.
>
> As far as I know, this is part of the plan on improving how user space and
> kernel
Thanks.
On Sat, Aug 3, 2013 at 2:20 PM, Ben Pfaff wrote:
> On Sat, Aug 03, 2013 at 12:23:14PM -0700, Andy Zhou wrote:
> > When verbose mode tuned on, all dp flow fields described by the netlink
> > attributes are displayed, including fully wildcarded attributes.
> > Otherwise, the fully wildcar
No problem. Your version is better.
On Sat, Aug 3, 2013 at 2:21 PM, Ben Pfaff wrote:
> On Sat, Aug 03, 2013 at 12:23:16PM -0700, Andy Zhou wrote:
> > Document the added -m option.
> >
> > Signed-off-by: Andy Zhou
>
> I didn't notice this until I'd already written documentation myself and
> fol
Jesse, please feel free to correct me if I am wrong.
As far as I know, this is part of the plan on improving how user space and
kernel are treating missing attributes.
Missing attribute has to be interpreted to be some default value, and the
value is usually opaque to the other side of the protoc
The commit message doesn't say why. Why?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Sat, Aug 03, 2013 at 12:23:16PM -0700, Andy Zhou wrote:
> Document the added -m option.
>
> Signed-off-by: Andy Zhou
I didn't notice this until I'd already written documentation myself and
folded it into the first patch. We usually add documentation for a
feature in the same patch that adds
On Sat, Aug 03, 2013 at 12:23:14PM -0700, Andy Zhou wrote:
> When verbose mode tuned on, all dp flow fields described by the netlink
> attributes are displayed, including fully wildcarded attributes.
> Otherwise, the fully wildcarded attributes are omitted for brevity.
>
> Added -m option to "ovs-
I changed the commit message to this:
While this code is useful for debugging, removing it allows us to hide
ofproto_trace() in ofproto-dpif. ofproto_trace() is a complex function
which could be difficult to make "obviously" thread safe.
Thanks for the review,
Ethan
On Fri, Aug 2, 2013 at 10:25
Document the added -m option.
Signed-off-by: Andy Zhou
---
utilities/ovs-dpctl.8.in |3 +++
1 file changed, 3 insertions(+)
diff --git a/utilities/ovs-dpctl.8.in b/utilities/ovs-dpctl.8.in
index 2b0036c..b30541d 100644
--- a/utilities/ovs-dpctl.8.in
+++ b/utilities/ovs-dpctl.8.in
@@ -121,6
When verbose mode tuned on, all dp flow fields described by the netlink
attributes are displayed, including fully wildcarded attributes.
Otherwise, the fully wildcarded attributes are omitted for brevity.
Added -m option to "ovs-dpctl dump-flows" to enable verbose mode. It is
off by default.
Sign
Signed-off-by: Andy Zhou
---
lib/odp-util.c|8 ++--
tests/odp.at | 33 +++--
tests/ofproto-dpif.at | 18 +-
3 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/lib/odp-util.c b/lib/odp-util.c
index cc83fa5..78d
I imagine that you don't have a network device named port1. Try adding one
that you do (eth0?).
On Aug 3, 2013 3:17 AM, "f 62" wrote:
> Hi all,
>
> I am using openvswitch. I created a bridge named br1 and tried to
> add port port1, but port1 doesn't got added.
>
> Following are the ovs
Thanks Ben for the late night review an improving the commit message.
On Sat, Aug 3, 2013 at 12:18 AM, Ben Pfaff wrote:
> Thanks, Andy and Jesse, for the confirmation. I rewrote the commit
> message and applied this to master and branch-1.11 as follows.
>
> I'm really bleary-eyed tired. I hop
Hi all ,
I am having an issue with adding ports in ovs bridge. Though ovs-vsctl
doesn't show an error. But ovs-vswitchd.log shows the error.
Executing command : ovs-ofctl dump-ports br-int show only one port that is
LOCAL and the count also shows 1.
2013-08-03T11:34:09Z|6|memory|INFO|
20
Hi all,
I am using openvswitch. I created a bridge named br1 and tried to add
port port1, but port1 doesn't got added.
Following are the ovs-vswitchd log:
2013-08-03T09:49:51Z|1|vlog|INFO|opened log file
/var/log/openvswitch/ovs-vswitchd.log
2013-08-03T09:49:51Z|2|reconne
On Aug 3, 2013, at 12:23 AM, Ben Pfaff wrote:
> On Sat, Aug 03, 2013 at 12:22:09AM -0700, Justin Pettit wrote:
>> On Aug 2, 2013, at 11:07 PM, Ben Pfaff wrote:
>>
>>> On Fri, Aug 02, 2013 at 10:53:40PM -0700, Justin Pettit wrote:
> In the case where we do emit a "set" action, we un-wildcard
On Aug 2, 2013, at 11:13 PM, Ben Pfaff wrote:
> On Fri, Aug 02, 2013 at 10:57:53PM -0700, Justin Pettit wrote:
>> The ODP library has an optimization to not set a header if the field was
>> not changed, regardless of whether an action to set the field was
>> present. That library is also respon
On Sat, Aug 03, 2013 at 12:22:09AM -0700, Justin Pettit wrote:
> On Aug 2, 2013, at 11:07 PM, Ben Pfaff wrote:
>
> > On Fri, Aug 02, 2013 at 10:53:40PM -0700, Justin Pettit wrote:
> >>> In the case where we do emit a "set" action, we un-wildcard not just the
> >>> single field but all the fields
On Aug 2, 2013, at 11:07 PM, Ben Pfaff wrote:
> On Fri, Aug 02, 2013 at 10:53:40PM -0700, Justin Pettit wrote:
>>> In the case where we do emit a "set" action, we un-wildcard not just the
>>> single field but all the fields that have to be set in the datapath in
>>> one go. Is that necessary her
Thanks, Andy and Jesse, for the confirmation. I rewrote the commit
message and applied this to master and branch-1.11 as follows.
I'm really bleary-eyed tired. I hope the following is correct.
Thanks,
Ben.
--8<--cut here-->8--
From: Andy Zhou
Yes, this is my understanding as well.
I did not mention the implication of mega flow in the commit message
because it is not the problem. But it is important in discussing about the
solution.
Your summary provides a better and more complete picture.
thanks for the review.
On Fri, Aug 2, 2013 a
31 matches
Mail list logo