From patchwork Wed Jan 9 07:39:31 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: jianhai luan X-Patchwork-Id: 210638 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 07AC82C00B0 for ; Wed, 9 Jan 2013 18:40:00 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757286Ab3AIHj5 (ORCPT ); Wed, 9 Jan 2013 02:39:57 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:35325 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755884Ab3AIHj4 (ORCPT ); Wed, 9 Jan 2013 02:39:56 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r097dj61005611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jan 2013 07:39:46 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r097djj3001144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 07:39:45 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r097djqO017048; Wed, 9 Jan 2013 01:39:45 -0600 Received: from [10.182.37.92] (/10.182.37.92) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jan 2013 23:39:44 -0800 Message-ID: <50ED1EB3.3080605@oracle.com> Date: Wed, 09 Jan 2013 15:39:31 +0800 From: jianhai luan Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ian Campbell CC: xen-devel@lists.xensource.com, Jan Beulich , netdev@vger.kernel.org, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] xen-netback notify DomU to send ARP. References: <50EC099D.6020407@oracle.com> <50EC297A02000078000B3BB5@nat28.tlf.novell.com> <1357652541.7989.179.camel@zakaz.uk.xensource.com> <50EC3DFD.8060206@oracle.com> <1357660834.12649.103.camel@dagon.hellion.org.uk> In-Reply-To: <1357660834.12649.103.camel@dagon.hellion.org.uk> X-Source-IP: acsinet22.oracle.com [141.146.126.238] Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Sorry, My attachment is wrong, please check the patch. On 2013-1-9 0:00, Ian Campbell wrote: > On Tue, 2013-01-08 at 15:40 +0000, jianhai luan wrote: >> On 2013-1-8 21:42, Ian Campbell wrote: >>> On Tue, 2013-01-08 at 13:13 +0000, Jan Beulich wrote: >>>>>>> On 08.01.13 at 12:57, jianhai luan >>>>>>> wrote: >>>>> When Xen Dom0's network circumstance changed, DomU >>>>> should be notified in some special condition. For >>>>> example the below circumstance: >>>>> ping from Guest A to DomU: >>>>> Guest A --> eth0 - bond0 - xenbr0 --VIF(DOMU) >>>>> eth1 / >>>>> when eth0 inactive, and eth1 active. >>> How is eth0 failing? Are you unplugging it, un-enslaving it or >>> taking >>> some other sort of administrative action? >> In my emulation environment, i unplug it or ifdown the interface, > I expect these would behave rather different, since the affect of ifdown > looks rather different to an unplug from the PoV of the switch. > > Is the ifdown case something which you are trying to solve or just what > appeared to be a convenient test case? I'd be less inclined to worry > about explict admin actions such as that. > > Unplugging the cable should cause: > >>> Doesn't this state change cause the switch to which eth0 and eth1 >>> are >>> attached to forget the MAC tables associated with the eth0 port, >>> meaning >>> that subsequent traffic will be flooded until it learns that eth1 is >>> the >>> new port? > Ian > > From f1235377724b4363cba27ef8b29fb89e2b36189a Mon Sep 17 00:00:00 2001 From: Jason Luan Date: Fri, 28 Dec 2012 15:43:06 +0800 Subject: [PATCH] xen-netback notify DomU to send ARP. When Xen Dom0's network circumstance changed, DomU should be notified in some special condition. For example the below circumstance: ping from Guest A to DomU: Guest A --> eth0 - bond0 - xenbr0 --VIF(DOMU) eth1 / when eth0 inactive, and eth1 active. Guest A --> eth0 bond0 - xenbr0 --VIF(DOMU) eth1 / Guest A will don't reach to DomU. After Guest A send ARP request and DomU respond, Guest A will reach DomU. But some more second will be elapsed. eth0 bond0 - xenbr0 --VIF(DOMU) Guest A --> eth1/ If Xen netback watch the network change, will notify DomU by change it own status. So netfront will watch netback's change, and DomU send ARP initiative. Signed-off-by: Jason Luan --- drivers/net/xen-netback/xenbus.c | 36 ++++++++++++++++++++++++++++++++++++ 1 files changed, 36 insertions(+), 0 deletions(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index 410018c..ead1a28 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -26,6 +26,7 @@ struct backend_info { struct xenvif *vif; enum xenbus_state frontend_state; struct xenbus_watch hotplug_status_watch; + struct notifier_block vif_notifier; u8 have_hotplug_status_watch:1; }; @@ -34,11 +35,42 @@ static void connect(struct backend_info *); static void backend_create_xenvif(struct backend_info *be); static void unregister_hotplug_status_watch(struct backend_info *be); +#define nb_to_backend(nb) container_of(nb, struct backend_info, vif_notifier) +/** + * When network condition of vif change, notify the frontend. + */ +static int netback_netdev_event(struct notifier_block *this, + unsigned long event, void *ptr) +{ + struct net_device *event_dev = (struct net_device *)ptr; + struct backend_info *be = nb_to_backend(this); + + pr_debug("event_dev: %s, event: %lx\n", + event_dev ? event_dev->name : "None", event); + + if (!be->vif) + goto out; + + switch (event) { + case NETDEV_NOTIFY_PEERS: + /* Notify frontend to Send gratuitous ARP */ + xenbus_switch_state(be->dev, XenbusStateInitialised); + xenbus_switch_state(be->dev, XenbusStateConnected); + break; + default: + break; + } + +out: + return NOTIFY_DONE; +} + static int netback_remove(struct xenbus_device *dev) { struct backend_info *be = dev_get_drvdata(&dev->dev); unregister_hotplug_status_watch(be); + unregister_netdevice_notifier(&be->vif_notifier); if (be->vif) { kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE); xenbus_rm(XBT_NIL, dev->nodename, "hotplug-status"); @@ -129,6 +161,10 @@ static int netback_probe(struct xenbus_device *dev, /* This kicks hotplug scripts, so do it immediately. */ backend_create_xenvif(be); + /* Register Frontend Event Notify */ + (be->vif_notifier).notifier_call = netback_netdev_event; + register_netdevice_notifier(&be->vif_notifier); + return 0; abort_transaction: