On Tue, Nov 29, 2011 at 10:18:02PM -0800, Jesse Gross wrote:
>
> The main part that worries me about moving to a different approach is
> the impedance mismatch that occurs from the fact that Open vSwitch is
> modeling a switch and tc is not. As Jamal alluded to above, it's
> actually the bridge co
On Tue, Nov 29, 2011 at 10:21:32PM -0800, Jesse Gross wrote:
>
> It's userspace which is managing the entries in the kernel hash table
> and it has some intelligence about aging out entries (and specifically
> about doing it more aggressively as the number of entries increases),
> so it's not reall
On Tue, Nov 29, 2011 at 10:25:34PM -0800, Jesse Gross wrote:
> Hi Herbert and Jamal (and everyone else),
>
> Sorry about starting yet another thread but the other one went in so
> many directions that I think a lot of things got lost in it. As I
> mentioned before, I'd like to have a bit of a des
Hi Herbert and Jamal (and everyone else),
Sorry about starting yet another thread but the other one went in so
many directions that I think a lot of things got lost in it. As I
mentioned before, I'd like to have a bit of a design discussion of
what it would look like if Open vSwitch were to use s
On Mon, Nov 28, 2011 at 6:51 AM, Herbert Xu wrote:
> There are other issues with the hash implementation. For example,
> there seems to be no limit on the number of collisions in each
> bucket. As the hash table growth code simply continues when it
> fails to expand, this means that the number o
On Mon, Nov 28, 2011 at 5:04 AM, Herbert Xu wrote:
> On Wed, Nov 23, 2011 at 07:22:56AM -0500, jamal wrote:
>> I cant find one - you may. After staring at the code, I am also now
>> questioning if the existing bridge code couldnt have been re-used with
>> some small tweaks.
>
> I wasn't able to fi
On Tue, Nov 29, 2011 at 07:53:23PM -0800, Ethan Jackson wrote:
> This will simplify unit tests added in a future patch.
Looks good, thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, Nov 29, 2011 at 07:53:22PM -0800, Ethan Jackson wrote:
> This will marginally simplify some unit tests in a future patch.
Looks good. Thank you.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, Nov 29, 2011 at 07:53:21PM -0800, Ethan Jackson wrote:
> It's a bug if LACP is configured with a system ID of zero. This
> patch assert fails in this case.
Will the change to lacp_configure() have the desired effect? I think
that the common case is that lacp_create() creates an all-zeros
On Wed, Nov 30, 2011 at 10:17:46AM +0500, Hassan Khan wrote:
> Follow up debate on the fast path slow path issue...
Do you have something to say?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Follow up debate on the fast path slow path issue...
-Original Message-
From: dev-boun...@openvswitch.org [mailto:dev-boun...@openvswitch.org] On
Behalf Of dev-requ...@openvswitch.org
Sent: Tuesday, November 29, 2011 3:43 AM
To: dev@openvswitch.org
Subject: dev Digest, Vol 28, Issue 146
S
On Tue, Nov 29, 2011 at 09:09:57PM -0800, Ethan Jackson wrote:
> > For example, bridge_configure_datapath_id() calls
> > bridge_pick_local_hw_addr(), which uses
> > ofproto_is_mirror_output_bundle(), but the latter will only return a
> > correct value after bridge_configure_mirrors(). ?And we can't
> For example, bridge_configure_datapath_id() calls
> bridge_pick_local_hw_addr(), which uses
> ofproto_is_mirror_output_bundle(), but the latter will only return a
> correct value after bridge_configure_mirrors(). And we can't move
> bridge_configure_mirrors() before the loop that configures the
On Tue, Nov 29, 2011 at 07:53:20PM -0800, Ethan Jackson wrote:
> The bridge code was completely ignoring the lacp-system-id setting.
>
> Future patches will add tests which would have caught this issue.
>
> Bug #8516.
Looks good to me, thanks.
___
dev
On Tue, Nov 29, 2011 at 07:53:19PM -0800, Ethan Jackson wrote:
> The LACP code uses the bridge's datapath ID as it's system ID when
> something else hasn't been explicitly configured. Since LACP was
> configured before each bridge's datapath ID, the LACP module would
> be configured with a datapat
Looks good, thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Patch 2 and 3 of this series fix the actual bugs. The later
patches deal with avoiding similar bugs in the first place. The
first patch is style.
Ethan Jackson (7):
bridge: Remove redundant newline.
bridge: Configure datapath ID, before LACP.
bridge: Honor lacp-system-id other_config setti
This patch adds tests which check that configuration settings in
the database are reflected in the LACP module's appctl output.
---
tests/automake.mk |1 +
tests/lacp.at | 105
tests/testsuite.at |1 +
3 files changed, 107 inserti
This will simplify unit tests added in a future patch.
---
lib/lacp.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/lib/lacp.c b/lib/lacp.c
index 2e16385..ddfa4b2 100644
--- a/lib/lacp.c
+++ b/lib/lacp.c
@@ -25,6 +25,7 @@
#include "ofpbuf.h"
#include "pac
This will marginally simplify some unit tests in a future patch.
---
lib/lacp.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/lib/lacp.c b/lib/lacp.c
index 9e63bbb..2e16385 100644
--- a/lib/lacp.c
+++ b/lib/lacp.c
@@ -725,35 +725,35 @@ static void
d
It's a bug if LACP is configured with a system ID of zero. This
patch assert fails in this case.
---
lib/lacp.c|1 +
vswitchd/bridge.c |5 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/lib/lacp.c b/lib/lacp.c
index 22cba94..9e63bbb 100644
--- a/lib/lacp.c
++
The bridge code was completely ignoring the lacp-system-id setting.
Future patches will add tests which would have caught this issue.
Bug #8516.
---
vswitchd/bridge.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index ccf
The LACP code uses the bridge's datapath ID as it's system ID when
something else hasn't been explicitly configured. Since LACP was
configured before each bridge's datapath ID, the LACP module would
be configured with a datapath ID of zero which broke basic LACP
support.
Future patches will add t
---
vswitchd/bridge.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index d2dcd02..d085f47 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -2662,7 +2662,6 @@ port_configure_lacp(struct port *port, struct
lacp_settings *s)
Lists available for purchase
===
-->Medical Industry Marketing Lists
-->Email data for comnpanies in real estate, construction,architects,schools
etc..
-->Lists of online consumers
===
all USA data with emails
Thanksgiving special prici
On Wed, Nov 23, 2011 at 12:09 AM, Simon Horman wrote:
> Hi,
>
> I have observed the following crash below using the in-kernel packet generator
> with skb_clone set to a non-zero value.
It's not safe to do this with many software devices including OVS that
write into the skb. Linux 3.1 introduced
26 matches
Mail list logo
