From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id AB4C29E7 for ; Tue, 15 Dec 2015 14:18:24 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP; 15 Dec 2015 05:18:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,432,1444719600"; d="scan'208";a="874026201" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by fmsmga002.fm.intel.com with ESMTP; 15 Dec 2015 05:18:08 -0800 Date: Tue, 15 Dec 2015 21:18:12 +0800 From: Yuanhan Liu To: Thibaut Collet Message-ID: <20151215131812.GI29571@yliu-dev.sh.intel.com> References: <000001d133ed$b2446eb0$16cd4c10$@samsung.com> <20151211094934.GX29571@yliu-dev.sh.intel.com> <001c01d133fd$d3a7d870$7af78950$@samsung.com> <20151214035842.GB18437@pxdev.xzpeter.org> <20151215082324.GG29571@yliu-dev.sh.intel.com> <007f01d13715$042a0a80$0c7e1f80$@samsung.com> <20151215100548.GD32243@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dev@dpdk.org, Victor Kaplansky Subject: Re: [dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 13:18:25 -0000 On Tue, Dec 15, 2015 at 12:47:47PM +0100, Thibaut Collet wrote: > On Tue, Dec 15, 2015 at 12:43 PM, Thibaut Collet > wrote: > > > > > > > On Tue, Dec 15, 2015 at 11:05 AM, Peter Xu 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