[ovs-dev] [PATCH 2/2] [RFC] classifier: Add support for conjunctive matches.

[Jarno Rajahalme]

On Oct 30, 2014, at 1:43 PM, Ben Pfaff <blp at 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.

  Jarno