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 <je...@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) {
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
