On Thu, May 2, 2013 at 1:30 PM, Andy Zhou <az...@nicira.com> wrote:
> diff --git a/include/linux/openvswitch.h b/include/linux/openvswitch.h
> index e890fd8..6048e9b 100644
> --- a/include/linux/openvswitch.h
> +++ b/include/linux/openvswitch.h
> @@ -287,6 +313,8 @@ enum ovs_key_attr {
> OVS_KEY_ATTR_IPV4_TUNNEL, /* struct ovs_key_ipv4_tunnel */
> #endif
>
> + OVS_KEY_ATTR_MEGA = 60, /* Indicate a mega flow key */
> + OVS_KEY_ATTR_MASK = 61, /* Nested OVS_MASK_ATTR_* attributes */
I'm not really a big fan of having OVS_KEY_ATTR_MASK in the
ovs_key_attr namespace for two reasons:
* It's not really semantically equivalent and putting it at the end
to try to differentiate it seems somewhat ugly.
* New userspaces will not be able to communicate with old kernels
since they will reject an unknown flow attribute. This isn't
inherently a dealbreaker since it's OK for new programs to require new
features but it seems like it will result in a lot of extra detection
and compatibility logic in various places.
>From a compatibility perspective, it seems like the ideal thing to do
is to continue using the OVS_FLOW_ATTR_KEY for exact matches and then
have an additional flow attr that specifies wildcards using the same
format as the values. Old kernels would just ignore the wildcards and
install the exact match, in effect looking very similar to subfacets.
In fact, this would also allow the kernel to impose arbitrary
restrictions on the types of wildcards that it supports since it could
choose to ignore some wildcard fields but not others.
As far as the format of the wildcards, I think we could just list the
values that have some form of mask with missing values being
implicitly completely wildcarded. (note: I think it's actually
possible to require all types to be present without userspace needing
special knowledge of the kernel because it has the list of supported
types from the upcall. However, I don't think this is necessary.) If
entire wildcard flow is not present then the flow is exact match.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
