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 6DD8F58CF
 for <dev@dpdk.org>; Mon, 14 Dec 2015 04:58:53 +0100 (CET)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com
 (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])
 by mx1.redhat.com (Postfix) with ESMTPS id 37E15A92;
 Mon, 14 Dec 2015 03:58:52 +0000 (UTC)
Received: from pxdev.xzpeter.org (vpn1-6-34.pek2.redhat.com [10.72.6.34])
 by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 tBE3whmV010290
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Sun, 13 Dec 2015 22:58:49 -0500
Date: Mon, 14 Dec 2015 11:58:42 +0800
From: Peter Xu <peterx@redhat.com>
To: Pavel Fedin <p.fedin@samsung.com>, yuanhan.liu@linux.intel.com
Message-ID: <20151214035842.GB18437@pxdev.xzpeter.org>
References: <000001d133ed$b2446eb0$16cd4c10$@samsung.com>
 <20151211094934.GX29571@yliu-dev.sh.intel.com>
 <001c01d133fd$d3a7d870$7af78950$@samsung.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <001c01d133fd$d3a7d870$7af78950$@samsung.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: dev@dpdk.org
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: Mon, 14 Dec 2015 03:58:53 -0000

On Fri, Dec 11, 2015 at 01:22:23PM +0300, Pavel Fedin wrote:
>  BTW, it works, and it was my bad. openvswitch was configured incorrectly on the other side, vhost port number was different for
> some reason, while ruleset was the same. I reconfigured it and now everything migrates correctly, except increased downtime because
> of missing GARP (the guest misses some PINGs, then it retries ARP, which brings the link back up).

Hi,

When doing the ping, was it from the guest (to another host) or to
the guest (from another host)?

In any case, I still could not understand why the ping loss happened
in this test.

If ping from guest, no ARP refresh is required at all?

If ping to guest from outside, when the migration finishes on the
target side of qemu, qemu_self_announce() will be called. Although
we might see a warning like "Vhost user backend fails to broadcast
fake RARP" (notify is done by hacking vhost_user_receive(), even if
notify fails, things will still move on), QEMU should still send a
RARP onto the link.

Not sure whether I missed anything.

Thanks.
Peter