On Wed, Jun 24, 2015 at 01:52:46PM -0700, Jesse Gross wrote:
> On Wed, Jun 24, 2015 at 1:45 PM, Ben Pfaff <b...@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 <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) {
>
> 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.
That's fine, same conclusion here, wanted to make sure you were aware.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
