Signed-off-by: Ben Pfaff
---
ofproto/ofproto.c | 79 ++---
1 file changed, 27 insertions(+), 52 deletions(-)
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index c05afd6..09a07f6 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -3523
One difficult part of make flow_mods thread-safe is sorting out which
members of each structure can be modified under which locks and,
especially, documenting this in a way that makes it hard for programmers to
get it wrong later. The compiler provides some tools for us, however, and
'const' is on
Previously this parameter was useful for Clang locking annotations
but it isn't actually a locking requirement anymore, so remove
the parameter.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif.c |2 +-
ofproto/ofproto-provider.h |3 +--
ofproto/ofproto.c | 33 +++
Before OVS introduced threading, any given ``learn'' action took effect in
the flow table before the next incoming flow was set up. This meant that
if a packet came in, used ``learn'' to set up a flow to handle replies, and
then a reply came in, the reply would always hit the flow set up by the
``
This patch and the remaining ones in this series are superseded and
replaced by the ones in the "threaded-learning" series that I just posted.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
This is the first step toward making a global lock that protects everything
needed for updating the flow table. This commit starts out by merging one
lock into the new one, and later commits will continue that process.
The mutex is initially a recursive one, because I wasn't sure that there
were
These aren't used outside this file.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-provider.h |5 -
ofproto/ofproto.c |6 +++---
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/ofproto/ofproto-provider.h b/ofproto/ofproto-provider.h
index 3684b0c..d477434 10064
This function is trivial now but in an upcoming commit it will need to
become slightly more complicated, which makes writing it as a function
worthwhile.
Until then, this commit simplifies the logic, which was redundant since
the 'deletions' hmap always points into the 'pending' list anyway.
Sign
Signed-off-by: Ben Pfaff
---
lib/classifier.c |3 ++-
lib/classifier.h |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/classifier.c b/lib/classifier.c
index 93ee977..36eb1f0 100644
--- a/lib/classifier.c
+++ b/lib/classifier.c
@@ -500,8 +500,9 @@ cls_cursor_first
The cookie index is only used for flow_mods, so it makes sense to use this
global mutex.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-provider.h |5 +++--
ofproto/ofproto.c | 15 +++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/ofproto/ofproto-provid
We already had two queues that were suitable for replacement by this data
structure, and I intend to add another one later on.
Signed-off-by: Ben Pfaff
---
lib/automake.mk|2 ++
lib/guarded-list.c | 65 +++
lib/guarded-list.h | 36 +
A rwlock is suitable when one expects long hold times so there is a need
for some parallelism for readers. But when the lock is held briefly, it
makes more sense to use a mutex for two reasons. First, a rwlock is more
complex than a mutex so one would expect it to be more expensive to
acquire. S
I think that ->timeout_mutex and ->mutex were separate because the latter
(which was actually a rwlock named ->rwlock until recently) was held for
long periods of time, which meant that having a separate ->timeout_mutex
reduced lock contention. But ->mutex is now only held briefly, so it seems
rea
One goal we're moving toward is to be able to execute "learn" actions
in each thread that handles packets that arrive on an interface just before
we forward those packets. The planned strategy there is to have a global
lock that protects everything required to modify the flow table. Generally
thi
This permits code to ensure long-term access to a rule's actions
without holding a long-term lock on the rule's rwlock.
Signed-off-by: Ben Pfaff
---
ofproto/connmgr.c|4 +-
ofproto/ofproto-dpif-xlate.c | 16 +++--
ofproto/ofproto-dpif.c | 26 +---
ofproto/ofproto-dp
ofproto is too big anyway so we might as well move out code that can
reasonably live elsewhere.
Signed-off-by: Ben Pfaff
---
lib/ofp-actions.c | 24
lib/ofp-actions.h |1 +
ofproto/ofproto.c | 33 +
3 files changed, 30 insertions(+
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif.c | 64 ++--
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index b52d4ee..97735e2 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofpr
Taking a read-lock on the 'rwlock' member of struct rule prevents members
of the rule from changing. This is a short-term use of the 'rwlock': one
takes the lock, reads some members, and releases the lock.
Taking a read-lock on the 'rwlock' also prevents the rule from being freed.
This is often a
Until now, ofproto_add_flow() and ofproto_delete_flow() assumed that the
flow table could not change between its flow table check and its later
modification to the flow table. This assumption will soon be untrue, so
remove it.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto.c | 64 ++
These functions were identical but had different names (one just called
the other). Make them a single function.
Signed-off-by: Ben Pfaff
---
ofproto/ofproto.c | 35 +++
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/ofproto/ofproto.c b/ofproto
Before we introduced threading, any given ``learn'' action took effect in
the flow table before the next incoming flow was set up. This meant that
if a packet came in, used ``learn'' to set up a flow to handle replies, and
then a reply came in, the reply would always hit the flow set up by the
``l
Found by inspection.
Signed-off-by: Ben Pfaff
Acked-by: Ethan Jackson
---
ofproto/ofproto.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index 03738ab..e7ee60e 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -2982,7
Signed-off-by: Ben Pfaff
---
ofproto/ofproto.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index 388463a..b027873 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -1717,10 +1717,9 @@ ofproto_add_flow(struct ofproto *ofpro
Signed-off-by: Ben Pfaff
Signed-off-by: Ben Pfaff
---
ofproto/ofproto.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index 81b6c43..388463a 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -2276,7 +2276,7 @@ ofproto_r
Found by inspection.
Signed-off-by: Ben Pfaff
Acked-by: Ethan Jackson
---
ofproto/ofproto.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index 4d33de7..03738ab 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/of
Signed-off-by: Ben Pfaff
---
ofproto/ofproto.c | 125 +++--
1 file changed, 55 insertions(+), 70 deletions(-)
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index e7ee60e..81b6c43 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -2935
On Tue, Sep 10, 2013 at 09:17:10AM -0700, Andy Zhou wrote:
> I don't think OFPTC11_TABLE_MISS_MASK is a possible value. It is there to
> simply indicate there are 2 bits used for miss configuration. May be it
> should be outside of the enum definition?
I agree that OFPTC11_TABLE_MISS_MASK isn't a
OFPTC11_TABLE_MISS_MASK is not a valid configuration, but to indicate
there are only 2 bits being used for table miss configuration. Move
it out of the enum definition.
Reported-by: Simon Horman
Signed-off-by: Andy Zhou
---
include/openflow/openflow-1.1.h |3 ++-
1 file changed, 2 insertion
On Tue, Sep 10, 2013 at 3:37 PM, Ethan Jackson wrote:
> The default number of miss handlers should be the number of processors
> minus two to account for the dispatcher and main threads.
>
> Signed-off-by: Ethan Jackson
>
I was a little concerned about this but you said off-list that you couldn
The default number of miss handlers should be the number of processors
minus two to account for the dispatcher and main threads.
Signed-off-by: Ethan Jackson
---
ofproto/ofproto.c|5 +++--
vswitchd/vswitch.xml |2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/ofpr
On Tue, Sep 10, 2013 at 01:31:17PM -0700, Ethan Jackson wrote:
> Bug #19568.
> Signed-off-by: Ethan Jackson
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Applied, thanks.
On Tue, Sep 10, 2013 at 01:51:52PM -0700, Andy Zhou wrote:
> Sorry, I attached a wrong file. Try again.
>
>
> On Wed, Sep 4, 2013 at 3:37 PM, Ben Pfaff wrote:
>
> > The code that this changes checks for two values in icmpv6_type. The
> > new version of the code checks for one
Sorry, I attached a wrong file. Try again.
On Wed, Sep 4, 2013 at 3:37 PM, Ben Pfaff wrote:
> The code that this changes checks for two values in icmpv6_type. The
> new version of the code checks for one value in tp_src or a different
> value in tp_dst. Should it check for two values in tp_sr
On Fri, Sep 06, 2013 at 12:53:17PM -0700, Ethan Jackson wrote:
> Holding the mac learning rwlock while calling send_packet() which
> calls xlate_actions() is dangerous because somewhere deep in the chain
> the same lock might be acquired causing a deadlock. Though we haven't
> run into this proble
Thanks, I'll merge shortly.
On Tue, Sep 10, 2013 at 1:40 PM, Ben Pfaff wrote:
> On Tue, Sep 10, 2013 at 01:31:17PM -0700, Ethan Jackson wrote:
>> Bug #19568.
>> Signed-off-by: Ethan Jackson
>
> Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.
Not too worried about it.
Thanks for the review,
Ethan
On Tue, Sep 10, 2013 at 1:47 PM, Ben Pfaff wrote:
> On Fri, Sep 06, 2013 at 12:53:17PM -0700, Ethan Jackson wrote:
>> Holding the mac learning rwlock while calling send_packet() which
>> calls xlate_actions() is dangerous because somewhere d
Bug #19568.
Signed-off-by: Ethan Jackson
---
ofproto/ofproto.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index e7ee60e..a9a20b8 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -1290,7 +1290,6 @@ ofproto_run(struct ofpr
On Mon, Sep 09, 2013 at 02:36:50PM -0700, Ethan Jackson wrote:
> Acked-by: Ethan Jackson
>
>
> On Mon, Sep 9, 2013 at 2:22 PM, Ben Pfaff wrote:
> > Found by inspection.
> >
> > Signed-off-by: Ben Pfaff
Thanks for reviewing the first two patches. I applied these to
master. I applied the firs
Ben Pfaff wrote:
On Tue, Sep 10, 2013 at 03:26:48PM +0200, Martino Fornasa wrote:
This sounds very nice. Do you plan to make the result available to the
Open vSwitch community?
We do, as soon as we reach a decent stage in the porting.
In this moment we are dealing with stp-related components
I don't think OFPTC11_TABLE_MISS_MASK is a possible value. It is there to
simply indicate there are 2 bits used for miss configuration. May be it
should be outside of the enum definition?
On Sun, Sep 8, 2013 at 6:28 PM, Simon Horman wrote:
> It seems convenient and in keeping with other Open vS
On Tue, Sep 10, 2013 at 05:34:28PM +0200, Martino Fornasa wrote:
> Ben Pfaff wrote:
> >On Tue, Sep 10, 2013 at 03:26:48PM +0200, Martino Fornasa wrote:
> >This sounds very nice. Do you plan to make the result available to
> >the Open vSwitch community?
> We do, as soon as we reach a decent stage in
On Tue, Sep 10, 2013 at 03:26:48PM +0200, Martino Fornasa wrote:
> at M3S (http://www.m3s.it) we developed a complete implementation of
> the Rapid Spanning Tree Protocol (RSTP) as defined in the standard
> IEEE 802.1D-2004 (which is the evolution of the first standard
> defining RSTP, IEEE 802.1w)
Hi,
at M3S (http://www.m3s.it) we developed a complete implementation of the
Rapid Spanning Tree Protocol (RSTP) as defined in the standard IEEE
802.1D-2004 (which is the evolution of the first standard defining RSTP,
IEEE 802.1w). The implementation has been tested in a lab environment
and we
43 matches
Mail list logo
