On Thu, May 02, 2013 at 08:20:52PM -0700, Jesse Gross wrote:
> 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.
Regarding the latter, I suggested putting it at the end only because of
the precedent that this is where attributes go that are not yet
upstream.
> * 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.
Userspace needs to be able to figure out what kinds of megaflows are
acceptable to the kernel. My favorite possibility is that the kernel
promises that any field that it understands can have bitwise wildcard
matches, that is, every field is maskable.
This policy makes life easy for userspace, because any flow it wants
to set up in response to a packet arrival will ordinarily be a subset
of the packet's microflow. For example, if a TCP packet arrives, then
userspace will might want to set up a flow that matches on the entire
microflow, or on the microflow except one or both of the TCP ports, or
on just the destination MAC address from the microflow. In each of
those cases, userspace would know that the kernel would understand the
flow match.
This policy is not hard to implement in the kernel. If in the future
we add a new field that for some reason we do not want to make
maskable, we could still do that without breaking backward
compatibility, because userspace would already need changes to add
support for that new field. On the other hand, *removing* maskability
for a field would break compatibility, so if that is something we may
want to do, then we should choose a different policy.
When userspace cannot set up the exact kind of megaflow that it wants
to, it has to be able to fall back on setting up some other flow. If
we can use the "every field is maskable" policy, then this will never
happen, so it is not a major concern.
> 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.
It would be most convenient to take the existing Netlink protocol for
exact-match flows and extend it in a backward-compatible way to also
allow wildcarded matching. However, the handling of omitted fields
introduces a difficulty. In an OpenFlow flow expressed in NXM or OXM,
any field not included in the flow description is implicitly
wildcarded. This is a natural choice because most flows match only a
small subset of the available fields and because it lends itself well
to some extensions: if a switch adds support for matching a field, the
controller need not be changed unless it actually wants to match on
that field.
In a kernel flow expressed as Netlink attibutes, an omitted field
implicitly matches some "default" field value (e.g. zero). This is
the case for OVS_KEY_ATTR_PRIORITY, OVS_KEY_ATTR_SKB_MARK, and
OVS_KEY_ATTR_TUNNEL, for example. Kernel megaflows cannot change this
interpretation. The natural conclusion is that a megaflow must
explicitly list every wildcarded field. Unfortunately this lends
itself poorly to extensions, because when the kernel adds support for
a new field, userspace must be aware so that it can wildcard it (or
match on it).
Therefore, instead of compatibly extending the Netlink protocol for
exact-match flows, I suggested that we extend it incompatibly, changing
the interpretation of missing fields to indicate that the fields are
wildcarded. To retain overall compatibility, I suggested that we add a
new attribute to the Netlink messages, where necessary, that can pass a
wildcarded field.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
