It's possible to imagine that a switch might want to report additional
capabilities related to Geneve beyond just the number of options and
how much space they can consume. Some examples include additional
restrictions on parsing (if this command is used for non-OVS implementations
or OVS changes how it works) and per-packet actions that can't be done
generically (such as checksums or encryption). It's not yet clear if
these will be necessary or if OpenFlow is the right place to expose
them. However, it's easy to do now and there is very little cost so
it seems like a good idea to leave some additional reserved space.
Signed-off-by: Jesse Gross <je...@nicira.com>
---
include/openflow/nicira-ext.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/openflow/nicira-ext.h b/include/openflow/nicira-ext.h
index 465b19d..b56edb3 100644
--- a/include/openflow/nicira-ext.h
+++ b/include/openflow/nicira-ext.h
@@ -986,12 +986,12 @@ OFP_ASSERT(sizeof(struct nx_geneve_table_mod) == 8);
struct nx_geneve_table_reply {
ovs_be32 max_option_space; /* Maximum total of option sizes supported. */
ovs_be16 max_fields; /* Maximum number of match fields supported. */
- uint8_t pad[2];
+ uint8_t pad[10];
/* struct nx_geneve_map[0]; Array of maps between indicies and Geneve
options. The number of elements is
inferred from the length field in the
header. */
};
-OFP_ASSERT(sizeof(struct nx_geneve_table_reply) == 8);
+OFP_ASSERT(sizeof(struct nx_geneve_table_reply) == 16);
#endif /* openflow/nicira-ext.h */
--
2.1.4
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
