From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 3368E11C5 for ; Wed, 16 Dec 2015 03:50:11 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 15 Dec 2015 18:50:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,435,1444719600"; d="scan'208";a="618694472" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by FMSMGA003.fm.intel.com with ESMTP; 15 Dec 2015 18:50:09 -0800 Date: Wed, 16 Dec 2015 10:50:19 +0800 From: Yuanhan Liu To: Peter Xu Message-ID: <20151216025019.GN29571@yliu-dev.sh.intel.com> References: <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> <20151215131812.GI29571@yliu-dev.sh.intel.com> <20151216023803.GB20951@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151216023803.GB20951@pxdev.xzpeter.org> 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: Wed, 16 Dec 2015 02:50:12 -0000 On Wed, Dec 16, 2015 at 10:38:03AM +0800, Peter Xu wrote: > On Tue, Dec 15, 2015 at 04:07:57PM +0100, Thibaut Collet wrote: > > After a migration, to avoid netwotk outage, all interfaces of the guest > > must send a packet to update switches mapping (ideally a GARP). > > As some interfaces do not do it QEMU does it in behalf of the guest by > > sending a RARP (his RARP is not forged by the guest but by QEMU). This is > > the qemu_self_announce purpose that "spoofs" a RARP to all backend of guest > > ethernet interfaces. For vhost-user backend, QEMU can not do it directly > > and asks to the vhost-user backend to do it with the VHOST_USER_SEND_RARP > > request that contains the MAC address of the guest interface. > > > > Thibaut. > > Hi, Thibaut, > > Thanks for the explaination. > > Two more questions: > > 1. if vhost-user backend (or say, DPDK) supports GUEST_ANNOUNCE, and > send another RARP (or say, GARP, I will use RARP as example), > then there will be two RARP later on the line, right? (since the > QEMU one is sent unconditionally from qemu_announce_self). The one send by qemu_announce_self() will be caught by vhost_user_receive(), which ends up invoking vhost_user_migration_done(). And it will be dropped when VIRTIO_NET_F_GUEST_ANNOUNCE is negotiated there. > 2. if the only thing vhost-user backend is to send another same RARP > when got SEND_RARP request, why would it bother if QEMU will > unconditionally send one? (or say, I still do not know why we > need this SEND_RARP request, if the vhost-user backend is going > to do the same thing again as QEMU already does) Because that one is caught by vhost-user, and vhost-user just relays it to the backend when necessary (say when GUEST_ANNOUNCE is not supported)? --yliu