OpenFlow 1.4 and earlier always send the description of every port in
response to an OFPMP_PORT_DESC request. OpenFlow 1.5 proposes allowing
the controller to request a description of a single port. This commit
implements a prototype.
EXT-69.
Signed-off-by: Ben Pfaff
---
lib/ofp-msgs.h
This allows OF1.5 prototyping to take place in a natural way.
Signed-off-by: Ben Pfaff
---
FAQ| 5 +++
build-aux/extract-ofp-errors | 3 +-
build-aux/extract-ofp-msgs | 53
include/openflow/openflow-common.h | 8 +---
lib/
OpenFlow 1.4 and earlier always send the description of every group in
response to an OFPMP_GROUP_DESC request. OpenFlow 1.5 proposes allowing
the controller to request a description of a single group. This commit
implements a prototype.
EXT-69.
Signed-off-by: Ben Pfaff
---
lib/ofp-msgs.h
It's harder to calculate the number of ports in a given amount of space in
OpenFlow 1.4 and later, because the ofp_port structure becomes variable
length in those versions. This commit removes the one caller, replacing
it by a version that doesn't need to know the number of ports in advance.
Sign
Signed-off-by: Ben Pfaff
---
build-aux/extract-ofp-msgs | 1 +
include/openflow/openflow-1.4.h| 41 +++-
include/openflow/openflow-common.h | 3 +-
lib/ofp-msgs.h | 14 ++--
lib/ofp-util.c | 131 +++-
ofputil_put_phy_port() and ofputil_append_port_desc_stats_reply() had a
lot of code duplication. This reduces it: it deletes some specialized
code from ofputil_put_phy_port(), moving it into its caller
ofputil_put_switch_features_port() that actually needed it. That change
then allows ofputil_app
The main effect is to move these functions a little earlier in the file.
A secondary effect is to make it possible to use different error codes for
different kinds of properties. In particular, table features has different
error codes from other properties (yeah, terrible design, tell me about
it)
It should include OF1.4.
Signed-off-by: Ben Pfaff
---
lib/ofp-util.h | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/lib/ofp-util.h b/lib/ofp-util.h
index 782e512..f4b5f79 100644
--- a/lib/ofp-util.h
+++ b/lib/ofp-util.h
@@ -119,11 +119,9 @@ enum ofputil_protocol {
This implements some of the missing support for OF1.4. It also starts in
on OpenFlow 1.5 (which is still under development) by implementing EXT-69,
which allows a controller to request the description of one particular
group or port.
Ben Pfaff (9):
ofp-util: Fix definition of OFPUTIL_P_OF13_UP.
Each of these allows code in ofp-util.c to be simplified.
Signed-off-by: Ben Pfaff
---
lib/ofp-msgs.c| 25 +
lib/ofp-msgs.h| 3 +++
lib/ofp-util.c| 29 +
lib/ofp-util.h| 3 +--
ofproto/ofproto.c | 5 +
5 files changed, 39
On Thu, May 08, 2014 at 12:09:12PM +0900, YAMAMOTO Takashi wrote:
> On NetBSD, perl is usually installed as /usr/pkg/bin/perl.
>
> Signed-off-by: YAMAMOTO Takashi
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mail
The upcall hander keeps a hash table which hashes flow to a list of
corresponding packets. This used to be necessary as packets with the same flow
had similar actions and calculating actions used to be a performance bottleneck.
Now that userspace action calculation performance has improved, there i
On Thu, May 08, 2014 at 12:09:11PM +0900, YAMAMOTO Takashi wrote:
> Signed-off-by: YAMAMOTO Takashi
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Move operation needs to do RCU transaction on mask array. That could
make mask delete expensive.
On Wed, May 7, 2014 at 10:29 PM, Andy Zhou wrote:
> I have a high level question:
> Since mask can be moved around in the array without causing problem,
> when deleting a mask, why not simply move th
On Thu, May 08, 2014 at 12:09:10PM +0900, YAMAMOTO Takashi wrote:
> It turned out to be non-problem.
>
> Signed-off-by: YAMAMOTO Takashi
It did seem odd.
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/list
I have a high level question:
Since mask can be moved around in the array without causing problem,
when deleting a mask, why not simply move the highest
element over?
On Mon, Apr 7, 2014 at 3:00 PM, Pravin wrote:
> From: Pravin Shelar
>
> Along with flow-table rehashing OVS can compact masks arr
> Thanks for making it clear. This may be one of the reasons why I still
> see 0.1% test failure at 2x standard deviation. The expected number
> of packet per interface can be as low as 64. Another reason I find to
> be the variations in hash value computed from packet.
>
> Should we simply do "r
Thanks for making it clear. This may be one of the reasons why I still
see 0.1% test failure at 2x standard deviation. The expected number
of packet per interface can be as low as 64. Another reason I find to
be the variations in hash value computed from packet.
Should we simply do "random_uin32(
It turned out to be non-problem.
Signed-off-by: YAMAMOTO Takashi
---
vswitchd/automake.mk | 2 +-
vtep/automake.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/vswitchd/automake.mk b/vswitchd/automake.mk
index c445302..c45d01d 100644
--- a/vswitchd/automake.mk
+++ b
Signed-off-by: YAMAMOTO Takashi
---
vswitchd/automake.mk | 3 ++-
vtep/automake.mk | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/vswitchd/automake.mk b/vswitchd/automake.mk
index c45d01d..b75322f 100644
--- a/vswitchd/automake.mk
+++ b/vswitchd/automake.mk
@@ -31,7 +
On NetBSD, perl is usually installed as /usr/pkg/bin/perl.
Signed-off-by: YAMAMOTO Takashi
---
vswitchd/automake.mk | 2 +-
vtep/automake.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/vswitchd/automake.mk b/vswitchd/automake.mk
index b75322f..fd291ef 100644
--- a/
> On Wed, May 7, 2014 at 7:01 PM, YAMAMOTO Takashi
> wrote:
>>> Sorry I was not clear in the commit message. It is the average of the
>>> first interface. I will make it clear before pushing.
>>
>> thanks for clarification.
>> i think the average is not so important. hash colision is.
>> the wor
On Wed, May 7, 2014 at 7:01 PM, YAMAMOTO Takashi wrote:
>> Sorry I was not clear in the commit message. It is the average of the
>> first interface. I will make it clear before pushing.
>
> thanks for clarification.
> i think the average is not so important. hash colision is.
> the worst case is,
> Sorry I was not clear in the commit message. It is the average of the
> first interface. I will make it clear before pushing.
thanks for clarification.
i think the average is not so important. hash colision is.
the worst case is, two interfaces in the same bucket, one in the other.
in that case
Sorry I was not clear in the commit message. It is the average of the
first interface. I will make it clear before pushing.
On Wed, May 7, 2014 at 6:18 PM, YAMAMOTO Takashi wrote:
>> Raise the minimal per interface packet distribution from 7 to 24.
>>
>> With 256 packet distributing to 3 interfac
> Raise the minimal per interface packet distribution from 7 to 24.
>
> With 256 packet distributing to 3 interfaces, the expected packets per
> interface should be 256/3 = 85.3
>
> Tested with 200 runs, the average number of packet per interface is
> 85.9. close to the expected number, standard
> Acked-by: Pritesh Kothari
thanks. applied.
YAMAMOTO Takashi
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
> Yamamoto san, would you please take a look?
i'll take a look later.
YAMAMOTO Takashi
>
> On Wed, May 7, 2014 at 11:10 AM, Ben Pfaff wrote:
>> On Tue, May 06, 2014 at 10:46:45PM -0700, Andy Zhou wrote:
>>> Raise the minimal per interface packet distribution from 7 to 24.
>>>
>>> With 256 pack
Thanks Alex, applied to master and backported 2.0-2.2. I can also backport
to 1.10 and 1.11 if necessary.
I'll follow up on the warn patch in the other thread.
On 7 May 2014 19:58, Alex Wang wrote:
> Hey Joe,
>
> Sorry for the delayed review,
>
> Good to see this simpler version and fix of mem
Daniele, could you please review this?
Ethan
On Wed, May 7, 2014 at 1:39 PM, Ben Pfaff wrote:
> On Wed, May 07, 2014 at 01:36:49PM -0700, Ethan Jackson wrote:
>> Signed-off-by: Ethan Jackson
>
> I'll leave this one for someone who uses this script.
__
I assume you will back port this to branch-2.2
On Wed, May 7, 2014 at 1:13 PM, Ben Pfaff wrote:
> On Wed, May 07, 2014 at 01:01:56PM -0700, Andy Zhou wrote:
>> On Wed, May 7, 2014 at 12:13 PM, Andy Zhou wrote:
>> > I am looking at it.
>> >
>> > On Tue, May 6, 2014 at 12:50 PM, Ben Pfaff wrote:
Acked-by: Andy Zhou
How about fold in the following changes as well?
diff --git a/lib/ovs-thread.c b/lib/ovs-thread.c
index 83dfd62..9b6a9a5 100644
--- a/lib/ovs-thread.c
+++ b/lib/ovs-thread.c
@@ -62,7 +62,7 @@ static bool multithreaded;
\
error = pthread_##TYPE##_##FUN(&l->lock); \
On Wed, May 07, 2014 at 01:36:49PM -0700, Ethan Jackson wrote:
> Signed-off-by: Ethan Jackson
I'll leave this one for someone who uses this script.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, May 07, 2014 at 01:36:48PM -0700, Ethan Jackson wrote:
> This fixes the following warning in the DPDK code.
>
> ../lib/netdev-dpdk.c:790:31: error: passing 'const struct netdev *' to
> parameter of type 'struct netdev *' discards qualifiers
>
> Signed-off-by: Ethan Jackson
Acked-by: Ben
Signed-off-by: Ethan Jackson
---
utilities/ovs-dev.py | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/utilities/ovs-dev.py b/utilities/ovs-dev.py
index f73899b..7a4425f 100755
--- a/utilities/ovs-dev.py
+++ b/utilities/ovs-dev.py
@@ -28,7 +28,6 @@ BUILD_GCC = O
This fixes the following warning in the DPDK code.
../lib/netdev-dpdk.c:790:31: error: passing 'const struct netdev *' to
parameter of type 'struct netdev *' discards qualifiers
Signed-off-by: Ethan Jackson
---
lib/netdev-provider.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Yamamoto san, would you please take a look?
On Wed, May 7, 2014 at 11:10 AM, Ben Pfaff wrote:
> On Tue, May 06, 2014 at 10:46:45PM -0700, Andy Zhou wrote:
>> Raise the minimal per interface packet distribution from 7 to 24.
>>
>> With 256 packet distributing to 3 interfaces, the expected packets
On Wed, May 07, 2014 at 01:01:56PM -0700, Andy Zhou wrote:
> On Wed, May 7, 2014 at 12:13 PM, Andy Zhou wrote:
> > I am looking at it.
> >
> > On Tue, May 6, 2014 at 12:50 PM, Ben Pfaff wrote:
> >> Commit 2a3fb0aa3c (lacp: Don't lock potentially uninitialized mutex in
> >> lacp_status().) fixed o
On Wed, May 7, 2014 at 12:13 PM, Andy Zhou wrote:
> I am looking at it.
>
> On Tue, May 6, 2014 at 12:50 PM, Ben Pfaff wrote:
>> Commit 2a3fb0aa3c (lacp: Don't lock potentially uninitialized mutex in
>> lacp_status().) fixed one bug related to acquiring the file scope 'mutex'
>> without initializ
I am looking at it.
On Tue, May 6, 2014 at 12:50 PM, Ben Pfaff wrote:
> Commit 2a3fb0aa3c (lacp: Don't lock potentially uninitialized mutex in
> lacp_status().) fixed one bug related to acquiring the file scope 'mutex'
> without initializing it. However, there was at least one other, in
> lacp_u
On Wed, May 07, 2014 at 11:27:37AM -0700, Robert Love wrote:
> I'm not sure what coding standard is followed in the ovs code base.
> Is it the kernel's coding standard?
No. See the CodingStyle file. It's basically BSD style with 4-space
indents (not tabs).
___
OK, I'll apply it in a minute.
Also, I'm taking the liberty of interpreting your reply as an
Acked-by.
Thanks,
Ben.
On Wed, May 07, 2014 at 11:24:43AM -0700, Bruce Davie wrote:
> Ben,
> Thanks for the review. We have not yet tested any implementations of BFD on
> VTEPs, so I?m not too worried
On 05/07/2014 11:21 AM, Pravin Shelar wrote:
On Wed, May 7, 2014 at 8:49 AM, Rogers, Gerald wrote:
As for the formatting issues, is there a ³c² pretty print formatter I can
run on ovs_client.c to make it conform to coding standards?
I do not know such tool, I think you have to do it manually
On Wed, May 07, 2014 at 11:21:37AM -0700, Pravin Shelar wrote:
> On Wed, May 7, 2014 at 8:49 AM, Rogers, Gerald
> wrote:
> > As for the formatting issues, is there a ??c?? pretty print formatter I can
> > run on ovs_client.c to make it conform to coding standards?
>
> I do not know such tool, I
Ben,
Thanks for the review. We have not yet tested any implementations of BFD on
VTEPs, so I’m not too worried about backward compatibility. We discovered the
need for this change to BFD in the schema when looking at how we would
configure BFD tunnels terminating on several VTEPs managed by a
On Wed, May 7, 2014 at 8:49 AM, Rogers, Gerald wrote:
> Pravin,
>
> On the 1GB page question. The patch simply allocates the rings and
> creates a port. You can allocate more than a single 1 GB page, the
> restriction is that it would need 1GB pages. The entire Huge Page
> allocated by DPDK is
On Tue, May 06, 2014 at 12:50:10PM -0700, Ben Pfaff wrote:
> Commit 2a3fb0aa3c (lacp: Don't lock potentially uninitialized mutex in
> lacp_status().) fixed one bug related to acquiring the file scope 'mutex'
> without initializing it. However, there was at least one other, in
> lacp_unixctl_show()
On Tue, May 06, 2014 at 02:54:52PM -0700, Ashwin Swaminathan wrote:
> Added a Tunnel table to the VTEP schema that allows
> per-tunnel BFD configuration and status to be specified.
> Removed the BFD configuration/status from the
> Physical_Locator table.
>
> Signed-off-by: Ashwin Swaminathan
Thi
On Wed, May 07, 2014 at 04:59:45PM +1200, Simon Horman wrote:
> On Thu, May 01, 2014 at 08:02:32AM -0700, Ben Pfaff wrote:
> > On Thu, May 01, 2014 at 05:58:00PM +0900, Simon Horman wrote:
> > > On Wed, Apr 30, 2014 at 09:54:30AM +0900, YAMAMOTO Takashi wrote:
> > > > > On Tue, Apr 29, 2014 at 06:3
Acked-by: Ethan Jackson
On Fri, May 2, 2014 at 8:44 AM, Jarno Rajahalme wrote:
> Unless otherwise configured, the prefix trie lookup is enabled for
> IPv4 destination and source address fields. A new keyword "none" is
> accepted as the value of "prefixes" in the OVSDB Flow_Table column.
>
> Si
On Tue, May 06, 2014 at 10:46:45PM -0700, Andy Zhou wrote:
> Raise the minimal per interface packet distribution from 7 to 24.
>
> With 256 packet distributing to 3 interfaces, the expected packets per
> interface should be 256/3 = 85.3
>
> Tested with 200 runs, the average number of packet per i
Thx, applied and backported (to branch-2.2) both patches
On Wed, May 7, 2014 at 10:52 AM, Ethan Jackson wrote:
> Acked-by: Ethan Jackson
>
>
> On Wed, May 7, 2014 at 12:01 AM, Alex Wang wrote:
> > Commit 88bf179aa3 (bfd/cfm: Check status change before update
> > status to database.) used a bo
Acked-by: Ethan Jackson
On Wed, May 7, 2014 at 12:01 AM, Alex Wang wrote:
> Commit 88bf179aa3 (bfd/cfm: Check status change before update
> status to database.) used a boolean flag to trigger bfd status
> update. However, the flag is not set on bfd creation and deletion.
>
> To prevent any sta
Acked-by: Ethan Jackson
On Wed, May 7, 2014 at 12:01 AM, Alex Wang wrote:
> Commit 88bf179aa3 (bfd/cfm: Check status change before update
> status to database.) used a boolean flag to trigger cfm status
> update. However, the flag is not set on cfm creation and deletion.
> And this causes stal
Hey Ethan,
Could you review these two patches? Should be straightforward,
Thanks,
Alex Wang,
On Wed, May 7, 2014 at 12:01 AM, Alex Wang wrote:
> Commit 88bf179aa3 (bfd/cfm: Check status change before update
> status to database.) used a boolean flag to trigger cfm status
> update. However,
Acked-by: Pritesh Kothari
On May 6, 2014, at 5:02 PM, YAMAMOTO Takashi wrote:
> Co-authored-by: Ben Pfaff
> Signed-off-by: YAMAMOTO Takashi
> ---
> FAQ | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/FAQ b/FAQ
> index fc21af4..d3632f9 100644
> --- a/FA
On Wed, May 07, 2014 at 09:02:39AM +0900, YAMAMOTO Takashi wrote:
> Co-authored-by: Ben Pfaff
> Signed-off-by: YAMAMOTO Takashi
If I'm co-author then I guess you need this also:
Signed-off-by: Ben Pfaff
Thanks a lot!
Ben
___
dev mailing list
dev@op
Pravin,
On the 1GB page question. The patch simply allocates the rings and
creates a port. You can allocate more than a single 1 GB page, the
restriction is that it would need 1GB pages. The entire Huge Page
allocated by DPDK is passed to each Virtual Machine, and all VM¹s share
this memory. T
>>
>>
>> +/* Metadata. */
>> if (md) {
>> -flow->tunnel = md->tunnel;
>> -flow->in_port = md->in_port;
>> -flow->skb_priority = md->skb_priority;
>> -flow->pkt_mark = md->pkt_mark;
>> -flow->recirc_id = md->recirc_id;
>> -flow->dp_hash = md
Hey Joe,
Sorry for the delayed review,
Good to see this simpler version and fix of memory leak,
Acked-by: Alex Wang
Also, it would be interesting to see if we still need the warn, later,
i could not find an example where tnl_find_ofport() returns NULL in
tnl_port_reconfigure(),
___
Commit 88bf179aa3 (bfd/cfm: Check status change before update
status to database.) used a boolean flag to trigger cfm status
update. However, the flag is not set on cfm creation and deletion.
And this causes stale status in database which may confuse users.
This commit fixes the issue by making c
Commit 88bf179aa3 (bfd/cfm: Check status change before update
status to database.) used a boolean flag to trigger bfd status
update. However, the flag is not set on bfd creation and deletion.
To prevent any stale status in database, this commit makes bfd module
always set the flag on bfd creation
62 matches
Mail list logo
