From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: jasowang@redhat.com, willemdebruijn.kernel@gmail.com,
mkubecek@suse.cz, netdev@vger.kernel.org, vyasevic@redhat.com
Subject: Re: regression: UFO removal breaks kvm live migration
Date: Wed, 8 Nov 2017 18:01:22 +0200 [thread overview]
Message-ID: <20171108174633-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20171108.203231.310648804772108001.davem@davemloft.net>
On Wed, Nov 08, 2017 at 08:32:31PM +0900, David Miller wrote:
> From: Jason Wang <jasowang@redhat.com>
> Date: Wed, 8 Nov 2017 17:25:48 +0900
>
> > On 2017年11月08日 17:08, Willem de Bruijn wrote:
> >> That won't help in the short term. I'm still reading up to see if
> >> there are
> >> any other options besides reimplement or advertise-but-drop, such as
> >> an implicit trigger that would make the guest renegotiate. It's
> >> unlikely, but
> >> worth a look..
> >
> > Yes, this looks hard. And even if we can manage to do this, it looks
> > an overkill since it will impact all guest after migration.
>
> Like Willem I would much prefer "advertise-but-drop" if it works.
>
> In the long term feature renegotiation triggers are a must.
>
> There is no way for us to remove features otherwise.
Isn't this like most userspace ABI issues? Once you add them it's very hard
to remove them, even with negotiation - too much userspace just does
if (ret)
exit();
> In my opinion this will even make migrations more powerful.
I agree. Not sure how to avoid packet drops when doing this though.
And dropping a ton of TX packets isn't nice at all since
TX packets is what teaches the network about the new location
of the VM.
--
MST
prev parent reply other threads:[~2017-11-08 16:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-07 8:02 regression: UFO removal breaks kvm live migration Michal Kubecek
2017-11-08 3:36 ` Willem de Bruijn
2017-11-08 6:26 ` David Miller
2017-11-08 7:49 ` Jason Wang
2017-11-08 8:08 ` Willem de Bruijn
2017-11-08 8:25 ` Jason Wang
2017-11-08 11:32 ` David Miller
2017-11-08 12:53 ` Jason Wang
2017-11-08 12:58 ` David Miller
2017-11-10 5:32 ` Willem de Bruijn
2017-11-10 5:59 ` David Miller
2017-11-17 14:31 ` Willem de Bruijn
2017-11-17 14:48 ` Willem de Bruijn
2017-11-17 23:00 ` Willem de Bruijn
2017-11-08 16:01 ` Michael S. Tsirkin [this message]
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=20171108174633-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=davem@davemloft.net \
--cc=jasowang@redhat.com \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=vyasevic@redhat.com \
--cc=willemdebruijn.kernel@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.