netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf@suug.ch>
To: Jesse Gross <jesse@nicira.com>
Cc: David Miller <davem@davemloft.net>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Pravin Shelar <pshelar@nicira.com>,
	Tom Herbert <therbert@google.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	"dev@openvswitch.org" <dev@openvswitch.org>,
	netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH 6/6] openvswitch: Support VXLAN Group Policy extension
Date: Tue, 13 Jan 2015 01:02:13 +0000	[thread overview]
Message-ID: <20150113010213.GA20387@casper.infradead.org> (raw)
In-Reply-To: <CAEP_g=8TnrwdGiTOB_mKeQSsEakV8y2OU7_ARwi+j9WDYh=Wag@mail.gmail.com>

On 01/12/15 at 01:54pm, Jesse Gross wrote:
> On Mon, Jan 12, 2015 at 4:26 AM, Thomas Graf <tgraf@suug.ch> wrote:
> > +       if (tb[OVS_VXLAN_EXT_MAX])
> > +               opts.gbp = nla_get_u32(tb[OVS_VXLAN_EXT_MAX]);
> 
> Shouldn't this be OVS_VXLAN_EXT_GBP instead of OVS_VXLAN_EXT_MAX?
> (They have the same value.)

Good catch, thanks!

> > +       if (!is_mask)
> > +               SW_FLOW_KEY_PUT(match, tun_opts_len, sizeof(opts), false);
> > +       else
> > +               SW_FLOW_KEY_PUT(match, tun_opts_len, 0xff, true);
> 
> Have you thought carefully about how the masking model work as other
> extensions are potentially added? This was a little tricky with Geneve
> because I wanted to be able to match on both "no options present" as
> well as wildcard all options. The other interesting thing is how you
> serialize them back correctly to userspace, which was the genesis of
> the TUNNEL_OPTIONS_PRESENT flag.
> 
> My guess is that this may basically work fine now that there is only
> one extension present but it is important to think about how it might
> work with multiple independent extensions in the future. (I haven't
> thought about it, I'm just asking.)

I currently don't see a reason why adding another extension would be
a problem. It should work like Geneve options except that the order
of the options in the flow is given (struct vxlan_opts).

Matching on "no options present" is supported in the datapath by
via the TUNNEL_VXLAN_OPT flag although there is no way in user space
to express this intent yet. I haven't come across a need to support it
yet.

Since the Netlink API is decoupled from the datapath flow
representation, all of this can be changed if needed without breaking
the Netlink ABI.

> If you set Geneve options and output to a VXLAN port (or vice versa),
> you will get garbage, right? Is there any way that we can sanity check
> that?

What about if we only apply tun_info->options on Geneve if
TUNNEL_GENEVE_OPT is set and vice versa?

  reply	other threads:[~2015-01-13  1:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-12 12:26 [PATCH 0/6 net-next v3] VXLAN Group Policy Extension Thomas Graf
2015-01-12 12:26 ` [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented Thomas Graf
2015-01-12 12:26 ` [PATCH 2/6] vxlan: Group Policy extension Thomas Graf
2015-01-12 19:23   ` Jesse Gross
     [not found]     ` <CAEP_g=8TqGnftZa_scKODa2ra7gsV6ov_5J+Lbfq+4bFDZjiBw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-12 22:47       ` Thomas Graf
2015-01-12 22:50         ` Jesse Gross
2015-01-12 22:59           ` Thomas Graf
2015-01-12 23:19             ` Jesse Gross
2015-01-12 12:26 ` [PATCH 3/6] vxlan: Only bind to sockets with correct extensions enabled Thomas Graf
2015-01-12 12:26 ` [PATCH 4/6] openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS() Thomas Graf
2015-01-12 21:38   ` Jesse Gross
2015-01-12 23:00     ` Thomas Graf
     [not found] ` <cover.1421064100.git.tgraf-G/eBtMaohhA@public.gmane.org>
2015-01-12 12:26   ` [PATCH 5/6] openvswitch: Allow for any level of nesting in flow attributes Thomas Graf
2015-01-12 19:41     ` Jesse Gross
2015-01-12 23:04       ` Thomas Graf
2015-01-12 12:26 ` [PATCH 6/6] openvswitch: Support VXLAN Group Policy extension Thomas Graf
2015-01-12 21:54   ` Jesse Gross
2015-01-13  1:02     ` Thomas Graf [this message]
2015-01-13 22:15       ` Jesse Gross
     [not found]         ` <CAEP_g=9=am_n_aSjA8mxOaViUMEaJgfr8DpMG9GsbitJm8006w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-13 22:18           ` Thomas Graf
  -- strict thread matches above, loose matches on Subject: below --
2015-01-08 22:47 [PATCH 0/6 net-next v2] VXLAN Group Policy Extension Thomas Graf
2015-01-08 22:47 ` [PATCH 6/6] openvswitch: Support VXLAN Group Policy extension Thomas Graf
2015-01-07  2:05 [PATCH 0/6 net-next] VXLAN Group Policy Extension Thomas Graf
2015-01-07  2:05 ` [PATCH 6/6] openvswitch: Support VXLAN Group Policy extension Thomas Graf
2015-01-07 22:46   ` Jesse Gross
2015-01-07 23:01     ` Thomas Graf
2015-01-08  1:18       ` Jesse Gross
2015-01-08 10:22         ` Thomas Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150113010213.GA20387@casper.infradead.org \
    --to=tgraf@suug.ch \
    --cc=alexei.starovoitov@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dev@openvswitch.org \
    --cc=jesse@nicira.com \
    --cc=netdev@vger.kernel.org \
    --cc=pshelar@nicira.com \
    --cc=stephen@networkplumber.org \
    --cc=therbert@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).