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 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
