On Sat, Aug 13, 2016 at 10:02 PM, Ben Pfaff <b...@ovn.org> wrote: > On Fri, Jul 29, 2016 at 05:28:26PM +0000, Mickey Spiegel wrote: > > Could you expand on why priorities in a single stage aren't enough to > > satisfy the use case? > > > > <Mickey> > > If two features are configured independently with a mix of > > prioritized allow and drop rules, then with a single stage, a > > new set of ACL rules must be produced that achieves the same > > behavior. This is sometimes referred to as an "ACL merge" > > algorithm, for example: > > http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_ > paper09186a00800c9470.shtml#wp39514 > > > > In the worst case, for example when the features act on different > > packet fields (e.g. one on IP address and another on L4 port), > > the number of rules required can approach > > (# of ACL1 rules) * (# of ACL2 rules). > > > > While it is possible to code up such an algorithm, it adds > > significant complexity and complicates whichever layer > > implements the merge algorithm, either OVN or the CMS above. > > > > By using multiple independent pipeline stages, all of this > > software complexity is avoided, achieving the proper result > > in a simple and straightforward manner. > > > > Recent network hardware ASICs tend to have around 8 or 10 ACL > > stages, though they tend to evaluate these in parallel given > > all the emphasis on low latency these days. > > I guess that, in software, if there's a need for 2 of something, there's > usually a need for N of it, so I'd tend to prefer that instead of > hard-coding 2 stages of ACLs, we make N of them available (for perhaps N > == 8), especially given that you say hardware tends to work that way. > It's not really more expensive for OVS, and definitely not if only a few > of them are used. We might need to expand the number of logical tables, > since currently there are only 16 ingress tables and 16 egress tables, > but doubling them to 32 each wouldn't be a big deal. >
I did try to code the core part of the changes so that more ACL stages could be easily added in the future, but the code having to do with definition of the pipeline stages, associated functions, and nbctl is only coded for 2 stages at the moment. Let me think about the best way to generalize this. As far as need and usage, I guess the key question is whether features such as service function chaining and QoS marking will use generic ACL stages, or pipeline stages specifically coded for those features? In hardware switches, those type of features use many of the multiple ACL stages. The way I coded the patch, the fixed rules allowing and dropping certain flows regardless of user-defined ACL rules are duplicated in each ACL stage. However, I am not sure if those rules are necessary or make sense if the actions for that pipeline stage are redirect (for SFC) or QoS marking, rather than allow and drop. I need to think about it. I have moved on to other things temporarily, will come back to this patch if/when I have time to work on ACL tests, or if someone else adds ACL tests. Mickey > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
