[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