All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Thibaut Collet <thibaut.collet@6wind.com>
Cc: dev@dpdk.org, Victor Kaplansky <victork@redhat.com>
Subject: Re: [PATCH 0/4 for 2.3] vhost-user live migration support
Date: Tue, 15 Dec 2015 21:18:12 +0800	[thread overview]
Message-ID: <20151215131812.GI29571@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <CABUUfwOkSG92yJ_OH+un4Xp2v+9aN5O_z7Md9z-j-DgNkTwabg@mail.gmail.com>

On Tue, Dec 15, 2015 at 12:47:47PM +0100, Thibaut Collet wrote:
> On Tue, Dec 15, 2015 at 12:43 PM, Thibaut Collet <thibaut.collet@6wind.com>
> wrote:
> 
> >
> >
> > On Tue, Dec 15, 2015 at 11:05 AM, Peter Xu <peterx@redhat.com> wrote:
> >
> >> On Tue, Dec 15, 2015 at 11:45:56AM +0300, Pavel Fedin wrote:
> >> >  To tell the truth, i don't know. I am also learning qemu internals on
> >> the fly. Indeed, i see that it should announce itself. But
> >> > this brings up a question: why do we need special announce procedure in
> >> vhost-user then?
> >>
> >> I have the same question. Here is my guess...
> >>
> >> In customized networks, maybe people are not using ARP at all? When
> >> we use DPDK, we directly pass through the network logic inside
> >> kernel itself. So logically all the network protocols could be
> >> customized by the user of it. In the customized network, maybe there
> >> is some other protocol (rather than RARP) that would do the same
> >> thing as what ARP/RARP does. So, this SEND_RARP request could give
> >> the vhost-user backend a chance to format its own announce packet
> >> and broadcast (in the SEND_RARP request, the guest's mac address
> >> will be appended).
> >>
> >> CCing Victor to better know the truth...
> >>
> >> Peter
> >>
> >

Hey Thibaut,

First of all, thanks a lot for your lengthy explanation.

> > Hi,
> >
> > After a migration, to avoid network outage, the guest must announce its
> > new location to the L2 layer, typically with a GARP. Otherwise requests
> > sent to the guest arrive to the old host until a ARP request is sent (after
> > 30 seconds) or the guest sends some data.
> >
> > QEMU implementation of self announce after a migration with a vhost
> > backend is the following:
> >  - If the VIRTIO_GUEST_ANNOUNCE feature has been negotiated the guest
> > sends automatically a GARP.

I'm kind of clear how VIRTIO_GUEST_ANNOUNCE works so far, except that I
met a bug, which I will describe in another email.

> >  - Else if the vhost backend implements VHOST_USER_SEND_RARP this request
> > is sent to the vhost backend. When this message is received the vhost
> > backend must act as it receives a RARP from the guest (purpose of this RARP

Can you be more specific about this? Say, what kind of acts the vhost
backend should do exactly?

> > is to update switches' MAC->port maaping as a GARP).

Isn't it vhost library is not aware of swtich at all? How could we
update switches's MAC-port mapping inside vhost library?

> This RARP is a false
> > one, created by the vhost backend,

I'm a bit confused now. You were just saying "vhost backend must act
as it __recevives__ a RARP from the guest", and you are now saying
"the RARP is a false one __created__ by the vhost backend".

Thanks.

	--yliu

  parent reply	other threads:[~2015-12-15 13:18 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-11  8:26 [PATCH 0/4 for 2.3] vhost-user live migration support Pavel Fedin
2015-12-11  9:49 ` Yuanhan Liu
2015-12-11 10:22   ` Pavel Fedin
2015-12-14  3:58     ` Peter Xu
2015-12-14  7:30       ` Pavel Fedin
2015-12-14  9:04         ` Peter Xu
2015-12-14  9:46           ` Pavel Fedin
2015-12-14 10:09             ` Peter Xu
2015-12-14 12:09             ` Yuanhan Liu
2015-12-14 13:00               ` Peter Xu
2015-12-14 13:21                 ` Yuanhan Liu
2015-12-14 13:28                   ` Peter Xu
2015-12-14 13:51                     ` Yuanhan Liu
2015-12-14 14:54                   ` Pavel Fedin
2015-12-15  8:23       ` Yuanhan Liu
2015-12-15  8:45         ` Pavel Fedin
2015-12-15  8:56           ` Yuanhan Liu
2015-12-15  9:04             ` Pavel Fedin
2015-12-15 10:05           ` Peter Xu
2015-12-15 11:43             ` Thibaut Collet
2015-12-15 11:47               ` Thibaut Collet
2015-12-15 12:24                 ` Pavel Fedin
2015-12-15 13:36                   ` Yuanhan Liu
2015-12-15 13:48                     ` Pavel Fedin
2015-12-15 13:59                       ` Yuanhan Liu
2015-12-15 14:58                         ` Pavel Fedin
2015-12-16  7:28                           ` Yuanhan Liu
2015-12-16 11:57                             ` Pavel Fedin
2015-12-16 12:08                               ` Yuanhan Liu
2015-12-16 12:43                                 ` Pavel Fedin
2015-12-16 13:00                                   ` Yuanhan Liu
2015-12-15 13:18                 ` Yuanhan Liu [this message]
2015-12-15 15:07                   ` Thibaut Collet
2015-12-15 15:36                     ` Pavel Fedin
2015-12-16  2:38                     ` Peter Xu
2015-12-16  2:50                       ` Yuanhan Liu
2015-12-16  7:05                       ` Pavel Fedin
2015-12-15  9:42         ` Peter Xu
  -- strict thread matches above, loose matches on Subject: below --
2015-12-02  3:43 Yuanhan Liu
2015-12-02 14:10 ` Victor Kaplansky
2015-12-02 14:33   ` Yuanhan Liu
2015-12-09  3:41 ` Xie, Huawei

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=20151215131812.GI29571@yliu-dev.sh.intel.com \
    --to=yuanhan.liu@linux.intel.com \
    --cc=dev@dpdk.org \
    --cc=thibaut.collet@6wind.com \
    --cc=victork@redhat.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.