This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH v3] xen-netfront: delay gARP until backend switch

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH v3] xen-netfront: delay gARP until backend switches to Connected
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Thu, 14 Jul 2011 08:41:06 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "lersek@xxxxxxxxxx" <lersek@xxxxxxxxxx>, "davem@xxxxxxxxxxxxx" <davem@xxxxxxxxxxxxx>
Delivery-date: Thu, 14 Jul 2011 00:41:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E1EA69C0200007800072E79@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <4E1EA69C0200007800072E79@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-07-14 at 08:19 +0100, Jan Beulich wrote:
> >>> Laszlo Ersek <lersek@xxxxxxxxxx> 07/13/11 6:11 PM >>>
> >After a guest is live migrated, the xen-netfront driver emits a
> gratuitous ARP
> >message, so that networking hardware on the target host's subnet can
> take
> >notice, and public routing to the guest is re-established. However,
> if the
> >packet appears on the backend interface before the backend is added
> to the
> >target host's bridge, the packet is lost, and the migrated guest's
> peers become
> >unable to talk to the guest.
> >
> >A sufficient two-parts condition to prevent the above is:
> >
> >(1) ensure that the backend only moves to Connected xenbus state
> after its
> >hotplug scripts completed, ie. the netback interface got added to the
> bridge;
> >and
> >
> >(2) ensure the frontend only queues the gARP when it sees the backend
> move to
> >Connected.
> >
> >These two together provide complete ordering. Sub-condition (1) is
> satisfied
> >by pvops commit 43223efd9bfd.
> Is it guaranteed that either side not having the respective change
> will still work correctly with the other side having its part of the
> change?

Having only 43223efd9bfd in the backend certainly appears to work
without the frontend piece (or is at least no worse than today).

Since the backend goes to XenbusStateConnected with or without
43223efd9bfd I think this proposed frontend change is also safe
regardless of whether the backend contains 43222... or not.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>