[ovs-dev] [async 6/6] ofproto: Implement asynchronous OFPT_FLOW_MOD commands.
Ben Pfaff
blp at nicira.com
Mon Jun 6 23:20:32 UTC 2011
Good catch on 'actions'. Here's the fix:
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index ead35eb..abc8fac 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -2229,6 +2229,8 @@ modify_flows__(struct ofconn *ofconn, const struct flow_mod *fm,
if (!ofputil_actions_equal(fm->actions, fm->n_actions,
rule->actions, rule->n_actions)) {
ofoperation_create(group, rule, OFOPERATION_MODIFY);
+ rule->pending->actions = rule->actions;
+ rule->pending->n_actions = rule->n_actions;
rule->actions = ofputil_actions_clone(fm->actions, fm->n_actions);
rule->n_actions = fm->n_actions;
rule->ofproto->ofproto_class->rule_modify_actions(rule);
'victim' is initialized in add_flow():
...
group = ofopgroup_create_for_ofconn(ofconn, request, fm->buffer_id);
ofoperation_create(group, rule, OFOPERATION_ADD);
rule->pending->victim = victim;
...
I'll work on polishing this up, then.
On Mon, Jun 06, 2011 at 03:26:15PM -0700, Ethan Jackson wrote:
> The general approach seems fine to me. I was a bit confused by the
> 'ofoperation''s 'actions' and 'victim' fields which never seem to get
> populated. Are those supposed to be set by the dpif somehow?
>
> Ethan
>
> On Fri, May 27, 2011 at 14:25, Ben Pfaff <blp at nicira.com> wrote:
> > Some switching hardware takes a very long time to update its forwarding
> > rules, up to hundreds of milliseconds. ?It is undesirable for Open
> > vSwitch to block waiting this long for individual OpenFlow flow table
> > modification commands to complete. ?This commit enables ofproto to queue
> > up any number of independent flow table operations with asynchronous
> > completion.
More information about the dev
mailing list