On Thu, Oct 30, 2014 at 01:50:38PM -0700, Jarno Rajahalme wrote: > > On Oct 30, 2014, at 1:43 PM, Ben Pfaff <b...@nicira.com> wrote: > > > On Thu, Oct 30, 2014 at 08:26:15AM -0700, Ben Pfaff wrote: > >> On Thu, Oct 30, 2014 at 12:06:30PM +0100, Thomas Graf wrote: > >>> On 10/29/14 at 11:46pm, Ben Pfaff wrote: > >>>> A "conjunctive match" allows higher-level matches in the flow table, such > >>>> as set membership matches, without causing a cross-product explosion for > >>>> multidimensional matches. Please refer to the documentation that this > >>>> commit adds to ovs-ofctl(8) for a better explanation, including an > >>>> example. > >>> > >>> High level remark before I dig into the code: > >>> > >>> conjunction(id, k/n) > >>> > >>> I like n being the number of dimensions. I wonder whether we should > >>> have k start at 1 instead of 0 though. It would read as 1/2 - "1st > >>> dimension out of 2", 2/2 - "2nd dimension out of 2". > >> > >> I'd be happy with that as the formatted syntax, but due to the use of > >> bitmaps for the dimensions it would either cause extra +1/-1 in > >> different places, or change the limit from 64 to 63 dimensions (which is > >> probably still about 60 more than actually useful). > >> > >> I'll think about it for the next version. > > > > I decided to change the formatted representation but not the OpenFlow > > binary format; that is, the formatting and parsing code for the > > human-readable representation adds or subtracts one from the dimension > > numbers. > > > > This change will be in the next version I post. > > > >>>> - Fixing reg0 as the field to use for conjunctive match lookup doesn't > >>>> seem > >>>> too great. We could make it configurable per-flow, or we could add a > >>>> new > >>>> field specifically for this purpose. I am not sure that it should be > >>>> fixed to 32 bits, either. > >>> > >>> I guess we can't go wrong with a separate 64 bits field. > >> > >> We're starting to have a lot of fields. When struct flow exceeds 252 > >> (63 * 4) bytes, we'll have to change how struct miniflow works because > >> we can't make the 'map' member wider than 63 bits. Still, we do have > >> some room. > > > > Jarno also suggested using a dedicated field, so I went with that. At > > the moment it is 32 bits. That would not be difficult to change, but > > it would extend NXAST_CONJUNCTION from 16 to 24 bytes. > > Controllers are free to use all the additional metadata fields in > the conjunction rules as well to scope them down to a specific VNI, > for example. So a VNI need not be embedded into the conjunction > field.
Right. I think the conj_id field only needs to be big if for some reason multiple controllers need to generate many of them randomly for a single table with a small probability of collision. As long as you can use a counter or divide up the 32-bit range among controllers, 32 bits should be plenty (I can't imagine more than 4 billion conjunctive flows per OpenFlow table!). _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
