netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Benc <jbenc@redhat.com>
To: Pravin Shelar <pshelar@nicira.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net] openvswitch: Fix egress tunnel info.
Date: Wed, 7 Oct 2015 10:09:55 +0200	[thread overview]
Message-ID: <20151007100955.3f13120e@griffin> (raw)
In-Reply-To: <CALnjE+p2KQqZsgkHYsWrJfKUCev85eGH6TWdrQHTA-9KxO9tjQ@mail.gmail.com>

On Tue, 6 Oct 2015 14:16:02 -0700, Pravin Shelar wrote:
> When OVS needs to add a vxlan tunnel device, OVS can create the vxlan
> device and check the parameters for the flag. If the flag does not
> exist then fallback to vport-create.

You omitted the very important step, delete the device before falling
back.

This means that with older kernels, there will be an interface created
and destroyed shortly after. With all netlink notifications sent, all
tools listening for netlink events seeing the interface appear and go,
with this being logged in various places, etc. Sounds very hacky and
confusing to anyone watching their logs or output of such tools. That
is the confusion I was talking about.

> This only needs to be done for
> very first tunnel device. Thats how most of features are supported in
> OVS.

The big difference to the other features is this cannot be detected
until half way through the setup.

What I'm proposing instead is to introduce a way to clearly and
unambiguously detect whether lwtunnels are supported or not. We'll need
this anyway: kernel 4.3 won't really support IPv6 tunneling with ovs,
yet there's currently no way to determine whether it's supported or not
(and, unlike with lwtunnel detection, there's not even a hacky way).
Querying the datapath for the supported features is needed
nevertheless; it's only logical to use it for the lwtunnel vs. old
vport decision, too.

I don't understand why you're opposed to this: it's much cleaner and
there's no problem with lwtunnels not being used with the 4.3 kernel,
everything should work just fine.

 Jiri

-- 
Jiri Benc

  reply	other threads:[~2015-10-07  8:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-05 17:58 [PATCH net] openvswitch: Fix egress tunnel info Pravin B Shelar
2015-10-05 18:40 ` Jiri Benc
2015-10-05 19:37   ` Pravin Shelar
2015-10-06 15:56     ` Jiri Benc
2015-10-06 18:28       ` Pravin Shelar
2015-10-06 18:45         ` Jiri Benc
2015-10-06 18:55           ` Pravin Shelar
2015-10-06 19:03             ` Jiri Benc
2015-10-06 19:21               ` Pravin Shelar
2015-10-06 19:32                 ` Jiri Benc
2015-10-06 21:16                   ` Pravin Shelar
2015-10-07  8:09                     ` Jiri Benc [this message]
2015-10-07  9:34                       ` Thomas Graf
2015-10-07  9:53                         ` Jiri Benc
2015-10-07 17:19                       ` Pravin Shelar
2015-10-06 15:42 ` Jiri Benc
2015-10-06 18:26   ` Pravin Shelar
2015-10-06 18:55     ` Jiri Benc
2015-10-06 19:11       ` Pravin Shelar

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=20151007100955.3f13120e@griffin \
    --to=jbenc@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pshelar@nicira.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).