From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <peterx@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by dpdk.org (Postfix) with ESMTP id 8BCBEB62
 for <dev@dpdk.org>; Wed, 16 Dec 2015 03:38:13 +0100 (CET)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
 (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
 by mx1.redhat.com (Postfix) with ESMTPS id 4AA77C0B7E05;
 Wed, 16 Dec 2015 02:38:12 +0000 (UTC)
Received: from pxdev.xzpeter.org (vpn1-6-86.pek2.redhat.com [10.72.6.86])
 by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 tBG2c3bQ014884
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Tue, 15 Dec 2015 21:38:07 -0500
Date: Wed, 16 Dec 2015 10:38:03 +0800
From: Peter Xu <peterx@redhat.com>
To: Thibaut Collet <thibaut.collet@6wind.com>
Message-ID: <20151216023803.GB20951@pxdev.xzpeter.org>
References: <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>
 <CABUUfwO-6BUMc=VTnutOv5Lzx07acZnbrYG3e9pmDLJxhuK7Pg@mail.gmail.com>
 <CABUUfwOkSG92yJ_OH+un4Xp2v+9aN5O_z7Md9z-j-DgNkTwabg@mail.gmail.com>
 <20151215131812.GI29571@yliu-dev.sh.intel.com>
 <CABUUfwPQwv4SzYynAhkKyPPpr7CGeez5L+M3aGshSR6-M6wQiQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABUUfwPQwv4SzYynAhkKyPPpr7CGeez5L+M3aGshSR6-M6wQiQ@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: dev@dpdk.org, Victor Kaplansky <victork@redhat.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2015 02:38:13 -0000

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).

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)

Thanks in advance.
Peter