[ovs-dev] [ovs-discuss] [ACLv2 08/19] ofproto: Add may install parameter to OpenFlow flows.

Jesse Gross jesse at nicira.com
Fri Sep 4 22:36:28 UTC 2009

Ben Pfaff wrote:
> Jesse Gross <jesse at nicira.com> writes:
>> This controls whether exact match flows can be installed to the
>> kernel for a given OpenFlow flow.  This can be used to prevent
>> flows from being installed that require userspace processing.
> I'm not sure that this really works:
>         * For wildcarded flows, rule_create() will set may_install to false
>           (because rules are allocated with xcalloc()).  Your changes make
>           ofproto_add_flow() then set may_install as its caller intends,
>           but rule_create() has other callers that don't set may_install,
>           and so those callers' rules are screwed.  So at least we need
>           rule_create() to set may_install, probably just to "true" by
>           default.
>           Nothing ever updates may_install for wildcarded flows, so at
>           least that part is OK after flow creation.
>         * For exact-match flows, rule_make_actions() will reset may_install
>           whenever it regenerates the dataflow actions for the flow, so
>           whatever ofproto_add_flow() puts into may_install will get
>           overridden immediately by its call to rule_insert() because that
>           function internally calls rule_make_actions().
> It would be better if we could use the existing framework of computing
> may_install during xlate_actions().  Can that be made to work?

My first thought was to use the normal may_install framework.  However, 
this does not work for ingress rules that drop packets.  Since 
may_install is only computed during the NORMAL action (which is 
synonymous for permitting packets in this context), there is no 
opportunity to disallow installation in this scenario.

I added a second parameter to the rule struct that specifies whether 
that rule may ever be installed.  It's not all that great because it is 
somewhat confusing but I'm not sure there is really an alternative.

More information about the dev mailing list