On Wed, Mar 30, 2016 at 09:47:27PM -0700, Han Zhou wrote: > On Wed, Mar 30, 2016 at 4:48 PM, Ben Pfaff <b...@ovn.org> wrote: > > > > On Tue, Mar 29, 2016 at 04:55:11PM -0700, Han Zhou wrote: > > > Currently in physical_run() we added per-port loopback prevention > > > flows for all lports. The flows are actually required only for > > > local ports on the chassis. This change greatly reduces number of > > > flows in table 34. > > > > > > Signed-off-by: Han Zhou <zhou...@gmail.com> > > > > We could do this with a single logical flow of the form: > > > > match="(inport[0] && !outport[0]) || (!inport[0]) && outport[0]) || > > (inport[1] && !outport[1]) || (!inport[1]) && outport[1]) || > > ... > > (inport[15] && !outport[15]) || (!inport[15]) && outport[15])", > > actions="next;" > > > > That's a fairly inefficient solution due to the construction of the OVS > > classifier but we still might consider it at some point. > > > > I applied this to master, thanks! > > I was thinking about: > > match="inport == outport", actions="drop" > > And then I realized that this is not possible without big change to OVS > classifier. But I didn't thought of this smart bit-trick to implement the > comparison. Thanks for enlightening :)
Tricks like this can implement any comparison, but usually in a really inefficient manner. If we add OpenFlow extension actions for arithmetic, this particular operation could be efficient. For example, one table could do something equivalent to "reg0 = inport ^ outport;" or "reg0 = inport - outport;" and then the next one could have entries like this: priority=100, match="reg0 == 0", actions="drop;" priority=0, match="1;", actions="next;" However, this kind of thing doesn't generalize very nicely, so I've refrained from working on it. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev