Signed-off-by: Simon Horman
---
v4
As suggested by Ben Pfaff
* Rename ofp11_match_type as ofp_match_type.
It will also be used by Open Flow 1.2 as
no values have been removed or had their meaning changed
between Open Flow 1.1 and 1.2.
* Add ofp11_port_stats_request.
* Consolidate ofp11_flow
This is a first pass at adding include/openflow/openflow-1.2.h to
include enum and struct definitions for Open Flow 1.2 that
are not already covered by Open Flow 1.1.
Signed-off-by: Simon Horman
---
v4
* As suggested by Ben Pfaff
- Consolidate ofp12_match_type into ofp_match_type
- Don't a
* Move ofp_packet_in_reason into openflow-common.h as it
contains elements first defined in both the
Openflow 1.0 and 1.2 specifications.
* Move ofp_flow_removed_reason into openflow-common.h as
subsequent patches will add an element first defined in the
Openflow 1.1 specification.
Signed
Signed-off-by: Simon Horman
---
v4
* Do not add ofp10_aggregate_stats_request as it is identical
to ofp_flow_stats_request. As suggested by Ben Pfaff
v3
* No change
v2
* Initial Post
---
include/openflow/openflow-1.0.h | 19 +++
1 files changed, 19 insertions(+), 0 deletion
Hi,
this series adds enum and struct definitions for Open Flow 1.2 to Open
vSwitch. Some missing Open Flow 1.0 and 1.1 definitions have also been
added. None of the definitions added by this series are used yet, rather
this is preliminary work that an implementation could be based on.
Since v3 of
This corrects what appears to be an oversight
whereby uing32_t is used while all other structures
in the file make use of ovs_be* in place of uint*_t.
Signed-off-by: Simon Horman
---
include/openflow/nicira-ext.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include
Use ovs_be16 in place of uint16_t.
This corrects an error made by me when
adding ofp_queue_prop_min_rate.
Signed-off-by: Simon Horman
---
v4
* Initial post
---
include/openflow/openflow-common.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/openflow/openflow-
Thanks for doing this! Looks like it's on the right track.
I get the following errors when building this:
lib/cfm.c:324:1: warning: symbol 'cfm_get_rmp_health_stats' was not declared.
Should it be static?
lib/cfm.c:324:1: error: no previous prototype for ???cfm_get_rmp_health_stats???
[-Werror=m
On Thu, Mar 29, 2012 at 03:00:06PM -0700, Ethan Jackson wrote:
> Without this patch, using ovs-ofctl to add a rule which masks the
> vlan_tci field would not work as expected unless the protocol was
> explicitly set to NXM.
>
> Signed-off-by: Ethan Jackson
This is the right idea but I think that
Without this patch, using ovs-ofctl to add a rule which masks the
vlan_tci field would not work as expected unless the protocol was
explicitly set to NXM.
Signed-off-by: Ethan Jackson
---
lib/ofp-util.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/ofp-util.c b/lib/ofp-ut
The changes display the cfm_health of an interface. The cfm_health
is an exponential weighted moving average of the health of all
remote_mpids. The value can vary from 0 to 100, 100 being very healthy
and 0 being unhealthy.
Feature #10363
Requested-by: Ethan Jackson
Signed-off-by: Mehak Mahajan
[adding Justin and ovs-dev]
On Thu, Mar 29, 2012 at 08:58:54PM +0200, ravi.ke...@telekom.com wrote:
> Can you let me know some details on your non-IP testing? To mitigate your
> concern, the only non-IP I have tested is ARP traffic. Though it is unusual
> for ARP traffic to carry MPLS labels, th
> valgrind basically acts like a mark/sweep garbage collector. If it
> can arrive at memory block M by at least one path that follows only
> pointers to the start of memory blocks, then it considers M to
> definitely be reachable. If it can arrive at memory block M only by
> paths that include a
I pushed this series to master, thank you for looking it over.
On Thu, Mar 29, 2012 at 01:46:46PM -0700, Ben Pfaff wrote:
> valgrind basically acts like a mark/sweep garbage collector. If it
> can arrive at memory block M by at least one path that follows only
> pointers to the start of memory bl
valgrind basically acts like a mark/sweep garbage collector. If it
can arrive at memory block M by at least one path that follows only
pointers to the start of memory blocks, then it considers M to
definitely be reachable. If it can arrive at memory block M only by
paths that include a pointer to
Thanks Jesse,
I will have a look through the archives to find previous submitted patches for
QinQ.
As for the layered flow matching, you are right, I have been looking at it from
a purely theoretical point of view. Once I progress my trial a bit further I
will replay some real traffic traces t
I'm running valgrind 3.7.0 (the current release) and I see the error.
Not a high priority to upstream this btw. If it turns out to be
trivial though, may be nice.
Ethan
On Thu, Mar 29, 2012 at 12:18, Ben Pfaff wrote:
> On Thu, Mar 29, 2012 at 12:16:05PM -0700, Ethan Jackson wrote:
>> > Wow thi
I'm not sure I fully understand this one. Does valgrind always report
a warning for structures with hmap_nodes or list_nodes that aren't at
the front? If not what are the conditions cause the leak to be
reported? If so, how can this possibly work for structures that have
both an hmap_node or lis
On Thu, Mar 29, 2012 at 12:16:05PM -0700, Ethan Jackson wrote:
> > Wow this is annoying. Seems like a reasonable solution to the
> > problem. Looks good.
>
> Actually come to think of it, does it make sense to upstream something
> like this to valgrind?
Possibly it has been already, I'm using v
Looks good thanks.
Ethan
On Wed, Mar 28, 2012 at 14:58, Ben Pfaff wrote:
> When ovsdb-server exits gracefully it frees all the memory that it owns,
> which keeps valgrind from warning about "possibly lost" blocks.
>
> Signed-off-by: Ben Pfaff
> ---
> tests/ofproto.at | 1 +
> test
> Wow this is annoying. Seems like a reasonable solution to the
> problem. Looks good.
Actually come to think of it, does it make sense to upstream something
like this to valgrind?
Ethan
>
> Ethan
>
> On Wed, Mar 28, 2012 at 14:58, Ben Pfaff wrote:
>> valgrind reports a memory leak and a par
Wow this is annoying. Seems like a reasonable solution to the
problem. Looks good.
Ethan
On Wed, Mar 28, 2012 at 14:58, Ben Pfaff wrote:
> valgrind reports a memory leak and a parameter error in glibc's
> timer_create() in almost every program execution. I don't know a way to
> avoid them.
>
Looks good, thank you.
Ethan
On Wed, Mar 28, 2012 at 14:58, Ben Pfaff wrote:
> All of these leaks are in normally short-lived programs, so none of them
> is very important.
>
> Signed-off-by: Ben Pfaff
> ---
> lib/ovsdb-data.c | 3 ++-
> ovsdb/ovsdb-client.c | 9 +
> ovsdb/
Thanks Justin and Ethan, for your assistance !!!
I will look into this. I am currently reading porting, design and other
documents.
If I come across any difficulties I will mail you.
Thanks again.
Looking forward to work with you for OVS (openflow).
- Hitesh
On Thu, Mar 29, 2012 at 3:48 AM,
On Thu, Mar 29, 2012 at 01:09:52PM +0900, Simon Horman wrote:
> On Wed, Mar 28, 2012 at 12:34:53PM -0700, Ben Pfaff wrote:
> > I don't think experimenter stats are actually different in 1.1 and
> > 1.2, although the sections are worded differently.
>
> It seems to me that ofp11_experimenter_stats_
25 matches
Mail list logo
