> On Oct 9, 2013, at 6:32 PM, Luigi Rizzo <[email protected]> wrote: > >> On Wed, Oct 09, 2013 at 06:22:25PM -0700, Reid Price wrote: >> Hi Luigi, >> >> At some level it is a logical error to create flows that: >> - have the same priority >> - have overlapping match criteria >> - have different actions >> >> You are already in trouble if you have >> >> priority=100, nw_src=1.2.3.0/24,actions=1 >> priority=100, nw_dst=5.6.7.0/24,actions=2 > > Sorry if i was unclear, i am not too familiar with ovs syntax. > > In the example i meant that the four entries should be analysed in > order of appeareance (similar to what happens e.g. in ipfw) > so that the first match wins. Does it translate to have to use > different priorities ? So then, does the priority field > also affect the creation and ordering of hash tables ? > That would explain things >
The match order is determined with priorities rather than the order of the flow entries. When a match is found, all other entries with same or lower priority are ignored. This has the corresponding effect on the kernel masks, as you suspected. Jarno > cheers > luigi > >> Since the action performed for 1.2.3.X->5.6.7.X be arbitrary, >> most likely based upon the ordering of some internal hash. >> >> For your above confusion, then: >> >> A: 1.2.3.4 -> 5.6.7.8 (matches flow 1) >> B: 1.2.5.6 -> 5.6.7.8 (matches flow 3) >> >> if you have different actions: >> - there is already a problem, the action is arbitrary regardless >> if you have the same actions: >> - there is no problem, the action would be the same >> >> Hope this helps! >> >> -Reid >> >> >>> On Wed, Oct 9, 2013 at 6:15 PM, Luigi Rizzo <[email protected]> wrote: >>> >>>> On Wed, Oct 09, 2013 at 05:59:43PM -0700, Ben Pfaff wrote: >>>> Your question deserves a more detailed answer, but here's an easy part. >>>> >>>>> On Thu, Oct 10, 2013 at 02:54:19AM +0200, Luigi Rizzo wrote: >>>>> Perhaps a simple example could help me -- e.g. say you have these >>>>> four flow entries, how many hash tables are created with megaflows ? >>>>> >>>>> (1) nw_src=1.2.3.0/24 ... >>>>> (2) nw_src=1.2.4.0/24 ... >>>>> (3) nw_dst=5.6.7.0/24 ... >>>>> (4) nw_src=1.2.5.0/24 ... >>>> >>>> Two, one for flows 1, 2, and 4 (since they match on the same bits of the >>>> same field), and one for flow 3 (which matches on a different field >>>> entirely). >>> >>> thanks. >>> the thing i do not understand is, these two packets >>> >>> A: 1.2.3.4 -> 5.6.7.8 (matches flow 1) >>> B: 1.2.5.6 -> 5.6.7.8 (matches flow 3) >>> >>> match different flows, but if we only have two hash tables in the kernel >>> (and they match both) how do we make sure that they are classified >>> properly (A could be misclassified as flow 3 if the table for nw_dst/24 >>> comes first; conversely, B could be misclassified as flow 4 if >>> the other hash table comes first) >>> >>> I suppose I am missing some details in my description of the scheme. >>> >>> cheers >>> luigi >>> >>>> The megaflows kernel design is similar to the userspace classifier. The >>>> main difference is that overlapping flows aren't allowed, so that any >>>> match that is found can be accepted. >>> _______________________________________________ >>> dev mailing list >>> [email protected] >>> http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > [email protected] > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
