On Thu, May 2, 2013 at 9:34 PM, Ben Pfaff <b...@nicira.com> wrote:
> 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.
Ben, I read your earlier email. Can you please read what I wrote
rather than just cutting and pasting?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
