[ovs-dev] [PATCH 07/11] openflow: Table maintenance commands for Geneve options.

[Jesse Gross]

On Wed, Jun 24, 2015 at 1:45 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Fri, Jun 19, 2015 at 04:13:21PM -0700, Jesse Gross wrote:
>> In order to work with Geneve options, we need to maintain a mapping
>> table between an option (defined by <class, type, length>) and
>> an NXM field that can be operated on for the purposes of matches,
>> actions, etc. This mapping must be explicitly specified by the
>> user.
>>
>> Conceptually, this table could be communicated using either OpenFlow
>> or OVSDB. Using OVSDB requires less code and definition of extensions
>> than OpenFlow but introduces the possibility that mapping table
>> updates and flow modifications are desynchronized from each other.
>> This is dangerous because the mapping table signifcantly impacts the
>> way that flows using Geneve options are installed and processed by
>> OVS. Therefore, the mapping table is maintained using OpenFlow commands
>> instead, which opens the possibility of using synchronization between
>> table changes and flow modifications through barriers, bundles, etc.
>>
>> There are two primary groups of OpenFlow messages that are introduced
>> as Nicira extensions: modification commands (add, modify, delete,
>> clear mappings) and table status request/reply to dump the current
>> table along with switch information.
>>
>> Note that mappings should not be changed while they are in active use by
>> a flow. The result of doing so is undefined.
>>
>> This only adds the OpenFlow infrastructure but doesn't actually
>> do anything with the information yet after the messages have been
>> decoded.
>>
>> Signed-off-by: Jesse Gross <jesse at nicira.com>
>
> Oh, also GCC reports:
>
>     ../lib/ofp-util.c: In function 'decode_geneve_table_mappings':
>     ../lib/ofp-util.c:8958:24: error: comparison is always true due to limited range of data type [-Werror=type-limits]
>              if (map->index >= TUN_METADATA_NUM_OPTS) {

Yeah, I actually knew about this one. It's because this patch only
contains the OpenFlow infrastructure for mapping options but not the
support for doing anything with them so the maximum number of options
is zero at this point. Therefore, the check for out of range indexes
is always true. It should get resolved in patch 10, I guess it didn't
seem worth doing weird things to avoid a transient warning.