xen-netback notify DomU to send ARP.

xen-netback notify DomU to send ARP.

[jianhai luan]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

Hi,
   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.

Thanks,
Jason

[-- Attachment #2: .0001-xen-netback-notify-DomU-to-send-ARP.patch.swp --]
[-- Type: application/octet-stream, Size: 12288 bytes --]

Re: [Xen-devel] xen-netback notify DomU to send ARP.

[Jan Beulich]

>>> On 08.01.13 at 12:57, jianhai luan <jianhai.luan@oracle.com> 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.
>    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/

Isn't a change to the availability of the bonds supposed to be
transparent to Guest A _and_ DomU? I.e. aren't you trying to fix
an eventual problem here in the wrong place?

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

Your patch is, at least according to what I see, completely
unusable - line breaks dropped, line order reversed, and
(guessing) some UTF-16/UCS-2 characters inserted at the top.
Please attach patches as plain ASCII.

Jan

Re: [Xen-devel] xen-netback notify DomU to send ARP.

[Ian Campbell]

On Tue, 2013-01-08 at 13:13 +0000, Jan Beulich wrote:
> >>> On 08.01.13 at 12:57, jianhai luan <jianhai.luan@oracle.com> 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?

Which bonding mode are you using?

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?

> >    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/
> 
> Isn't a change to the availability of the bonds supposed to be
> transparent to Guest A _and_ DomU? I.e. aren't you trying to fix
> an eventual problem here in the wrong place?

In non-virtualised bonding the bonding drive can take care of some of
this because it knows its own MAC address and can send appropriate
gratuitous frames (depends on the bonding mode) to paper over things. In
the virtualised case it (most likely) doesn't know VIF(DOMU)s MAC
address.

> > 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.
> 
> Your patch is, at least according to what I see, completely
> unusable - line breaks dropped, line order reversed, and
> (guessing) some UTF-16/UCS-2 characters inserted at the top.
> Please attach patches as plain ASCII.

>From the name it looks to me like it is the vi temp file created while
you have the file open rather than the actual patch file...

Ian.

Re: xen-netback notify DomU to send ARP.

[jianhai luan]

[-- Attachment #1.1: Type: text/plain, Size: 2657 bytes --]


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 <jianhai.luan@oracle.com> 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, while 
eth0 maybe wrong in productive environment.
>
> Which bonding mode are you using?
Bond running in active-backup mode.
>
> 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?
>
>>>     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/
>> Isn't a change to the availability of the bonds supposed to be
>> transparent to Guest A _and_ DomU? I.e. aren't you trying to fix
>> an eventual problem here in the wrong place?
> In non-virtualised bonding the bonding drive can take care of some of
> this because it knows its own MAC address and can send appropriate
> gratuitous frames (depends on the bonding mode) to paper over things. In
> the virtualised case it (most likely) doesn't know VIF(DOMU)s MAC
> address.
   If you have know all ip and mac before modprobe bond, you can 
configure the bond argument. But you don't know all ip and mac before 
start new virtual.
   If bond want to know all DomU's ip and mac which pass through, it 
must check all skb. it's not good idea.
>
>>> 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.
>> Your patch is, at least according to what I see, completely
>> unusable - line breaks dropped, line order reversed, and
>> (guessing) some UTF-16/UCS-2 characters inserted at the top.
>> Please attach patches as plain ASCII.
>  From the name it looks to me like it is the vi temp file created while
> you have the file open rather than the actual patch file...
>
> Ian.
>
Thanks,
Jason


[-- Attachment #1.2: Type: text/html, Size: 5439 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] xen-netback notify DomU to send ARP.

[Ian Campbell]

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 <jianhai.luan@oracle.com>
> > > > > > 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

Re: xen-netback notify DomU to send ARP.

[Jason Luan]

于 2013年01月09日 00:00, Ian Campbell 写道:
> 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 <jianhai.luan@oracle.com>
>>>>>>> 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:
>
I do above listed thing to let switch active slave only.
I think that we should put attention on the thing which bond switch 
active slave interface in active-backup mode. In network circumstance, 
many thing will cause the switch, what do Vif when the event happen?
>>> 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
>
>
>
> _______________________________________________
> Xen-devel mailing list
Thanks,
Jason
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] xen-netback notify DomU to send ARP.

[Ian Campbell]

On Wed, 2013-01-09 at 01:07 +0000, Jason Luan wrote:
> 于 2013年01月09日 00:00, Ian Campbell 写道:
> > 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 <jianhai.luan@oracle.com>
> >>>>>>> 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:
> >
> I do above listed thing to let switch active slave only.
> I think that we should put attention on the thing which bond switch 
> active slave interface in active-backup mode. In network circumstance, 
> many thing will cause the switch, what do Vif when the event happen?

Sorry, I'm having a bit of trouble parsing the above, but are you asking
what the VIF should do when the active slave in the bond changes without
the previously active slave actually failing?

The issue is that traffic will continue to arrive on the now inactive
slave, but will be discarded (the expected behaviour for
Active/Passive)?

Is this something which happens in practice? Does the active slave
change even while it remains a viable path?

Ian.

Re: [Xen-devel] xen-netback notify DomU to send ARP.

[jianhai luan]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

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 <jianhai.luan@oracle.com>
>>>>>>> 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
>
>


[-- Attachment #2: 0001-xen-netback-notify-DomU-to-send-ARP.patch --]
[-- Type: text/plain, Size: 3169 bytes --]

>From f1235377724b4363cba27ef8b29fb89e2b36189a Mon Sep 17 00:00:00 2001
From: Jason Luan <jianhai.luan@oracle.com>
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 <jianhai.luan@oracle.com>
---
 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:
-- 
1.7.6.5

Re: [Xen-devel] xen-netback notify DomU to send ARP.

[Jan Beulich]

>>> On 09.01.13 at 08:39, jianhai luan <jianhai.luan@oracle.com> wrote:
>@@ -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;

Pointless cast.

>+	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);

This is the sort of change that clearly isn't acceptable, as I don't
think you have ways to check _all_ existing frontends for their
compatibility with this. A connected -> connected transition
might be acceptable (that was done in the block frontend too, for
implementing dynamic resize), but will likely need to be
accompanied by a frontend side patch to handle that (which so
far should be a no-op).

>+		break;
>+	default:
>+		break;

Pointless default case.

>+	}
>+
>+out:

I don't think you really need the label (and the goto above) - just
put a return there.

>+	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;

Pointless parentheses.

Jan

>+	register_netdevice_notifier(&be->vif_notifier);
>+
> 	return 0;
> 
> abort_transaction:

Re: [Xen-devel] xen-netback notify DomU to send ARP.

[jianhai luan]

[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]


On 2013-1-9 18:06, Jan Beulich wrote:
>>>> On 09.01.13 at 08:39, jianhai luan <jianhai.luan@oracle.com> wrote:
>> @@ -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;
> Pointless cast.
>
>> +	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, );
> This is the sort of change that clearly isn't acceptable, as I don't
> think you have ways to check _all_ existing frontends for their
> compatibility with this. A connected -> connected transition
> might be acceptable (that was done in the block frontend too, for
> implementing dynamic resize), but will likely need to be
> accompanied by a frontend side patch to handle that (which so
> far should be a no-op).
The latest xen net-frontent driver have handled the condition. State 
XenbusStateInitialised will do nothing,
but change to XenbusStateConnected will trigger 
netdev_notify_peers(netdev) to send ARP.
>
>> +		break;
>> +	default:
>> +		break;
> Pointless default case.
>
>> +	}
>> +
>> +out:
> I don't think you really need the label (and the goto above) - just
> put a return there.
>
>> +	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);
>>
>> +	/*   Event Notify */
>> +	(be->vif_notifier).notifier_call = netback_netdev_event;
> Pointless parentheses.
>
> Jan
>
>> +	register_netdevice_notifier(&be->vif_notifier);
>> +
>> 	return 0;
>>
>> abort_transaction:
>


[-- Attachment #2: 0001-xen-netback-notify-DomU-to-send-ARP.patch --]
[-- Type: text/plain, Size: 3126 bytes --]

>From a64d80cc0c780bee7a8d6e842126cb5f7d17f0d2 Mon Sep 17 00:00:00 2001
From: Jason Luan <jianhai.luan@oracle.com>
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 <jianhai.luan@oracle.com>
---
 drivers/net/xen-netback/xenbus.c |   33 +++++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..17a3990 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,39 @@ 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 = 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)
+		return NOTIFY_DONE;
+
+	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;
+	}
+
+	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 +158,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:
-- 
1.7.6.5

Re: [Xen-devel] xen-netback notify DomU to send ARP.

[Jan Beulich]

>>> On 09.01.13 at 13:28, jianhai luan <jianhai.luan@oracle.com> wrote:
>>> +	switch (event) {
>>> +	case NETDEV_NOTIFY_PEERS:
>>> +		/* Notify frontend to Send gratuitous ARP */
>>> +		xenbus_switch_state(be->dev, XenbusStateInitialised);
>>> +		xenbus_switch_state(be->dev, );
>> This is the sort of change that clearly isn't acceptable, as I don't
>> think you have ways to check _all_ existing frontends for their
>> compatibility with this. A connected -> connected transition
>> might be acceptable (that was done in the block frontend too, for
>> implementing dynamic resize), but will likely need to be
>> accompanied by a frontend side patch to handle that (which so
>> far should be a no-op).
> The latest xen net-frontent driver have handled the condition. State 
> XenbusStateInitialised will do nothing,
> but change to XenbusStateConnected will trigger 
> netdev_notify_peers(netdev) to send ARP.

Did you read my earlier reply carefully? You still only talk about
(upstream) Linux netfront, but this is not the only (possible)
frontend. You should not invoke state transitions that can -
even if only theoretically - blow up frontends. And afaict the
only thing you can safely assume frontends ought to tolerate
are transitions from Connected to Connected (or more
generally from one state to the same one, but the other
states aren't useful here, except maybe the Reconfigur* ones).

Jan

Re: xen-netback notify DomU to send ARP.

[Jason Luan]

于 2013年01月09日 21:44, Jan Beulich 写道:
>>>> On 09.01.13 at 13:28, jianhai luan <jianhai.luan@oracle.com> wrote:
>>>> +	switch (event) {
>>>> +	case NETDEV_NOTIFY_PEERS:
>>>> +		/* Notify frontend to Send gratuitous ARP */
>>>> +		xenbus_switch_state(be->dev, XenbusStateInitialised);
>>>> +		xenbus_switch_state(be->dev, );
>>> This is the sort of change that clearly isn't acceptable, as I don't
>>> think you have ways to check _all_ existing frontends for their
>>> compatibility with this. A connected -> connected transition
>>> might be acceptable (that was done in the block frontend too, for
>>> implementing dynamic resize), but will likely need to be
>>> accompanied by a frontend side patch to handle that (which so
>>> far should be a no-op).
>> The latest xen net-frontent driver have handled the condition. State
>> XenbusStateInitialised will do nothing,
>> but change to XenbusStateConnected will trigger
>> netdev_notify_peers(netdev) to send ARP.
> Did you read my earlier reply carefully? You still only talk about
> (upstream) Linux netfront, but this is not the only (possible)
> frontend. You should not invoke state transitions that can -
> even if only theoretically - blow up frontends. And afaict the
I only want to notify xen-netfront. I don't know what is better way?
To attainthegoal, i try to modify virtual interrupt, but the way is
morecomplicated,modified and working. So, i give up the way.
Would you like to give some suggestion about how to notify xen-netfront?
> only thing you can safely assume frontends ought to tolerate
> are transitions from Connected to Connected (or more
> generally from one state to the same one, but the other
> states aren't useful here, except maybe the Reconfigur* ones).
Sorry for that. At the beginning the patch be applied in kernel 2.6.18 to
fixed one issue. Only XenbusStateInitialised and XenbusStateClosed ( Not
Reconfigure* one) don't any thing, so i choose the XenbusStateInitialised.
Do you suggestion that i choose Reconfigure*?
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] xen-netback notify DomU to send ARP.

[Jan Beulich]

>>> On 09.01.13 at 16:37, Jason Luan <luanjianhai@163.com> wrote:
> 于 2013年01月09日 21:44, Jan Beulich 写道:
>>>>> On 09.01.13 at 13:28, jianhai luan <jianhai.luan@oracle.com> wrote:
>>>>> +	switch (event) {
>>>>> +	case NETDEV_NOTIFY_PEERS:
>>>>> +		/* Notify frontend to Send gratuitous ARP */
>>>>> +		xenbus_switch_state(be->dev, XenbusStateInitialised);
>>>>> +		xenbus_switch_state(be->dev, );
>>>> This is the sort of change that clearly isn't acceptable, as I don't
>>>> think you have ways to check _all_ existing frontends for their
>>>> compatibility with this. A connected -> connected transition
>>>> might be acceptable (that was done in the block frontend too, for
>>>> implementing dynamic resize), but will likely need to be
>>>> accompanied by a frontend side patch to handle that (which so
>>>> far should be a no-op).
>>> The latest xen net-frontent driver have handled the condition. State
>>> XenbusStateInitialised will do nothing,
>>> but change to XenbusStateConnected will trigger
>>> netdev_notify_peers(netdev) to send ARP.
>> Did you read my earlier reply carefully? You still only talk about
>> (upstream) Linux netfront, but this is not the only (possible)
>> frontend. You should not invoke state transitions that can -
>> even if only theoretically - blow up frontends. And afaict the
> I only want to notify xen-netfront. I don't know what is better way?
> To attainthegoal, i try to modify virtual interrupt, but the way is
> morecomplicated,modified and working. So, i give up the way.
> Would you like to give some suggestion about how to notify xen-netfront?
>> only thing you can safely assume frontends ought to tolerate
>> are transitions from Connected to Connected (or more
>> generally from one state to the same one, but the other
>> states aren't useful here, except maybe the Reconfigur* ones).
> Sorry for that. At the beginning the patch be applied in kernel 2.6.18 to
> fixed one issue. Only XenbusStateInitialised and XenbusStateClosed ( Not
> Reconfigure* one) don't any thing, so i choose the XenbusStateInitialised.
> Do you suggestion that i choose Reconfigure*?

I already said that I think that only a Connected->Connected
transition is to be considered here. Bringing up Reconfigur* was
just to point out that there are other states available that could
be used, but you'd first need to make sure that (a) they aren't
used for anything else and (b) frontends can reasonably be
expected to deal with (ignore) them when not originally aware
of them (as opposed to a Connected->Connected transition,
which all frontends ought to be able to deal with afaict).

Also, when you reply to earlier mails, could you - in order to make
the result readable - insert blank lines between the quoted text
and your responses, please?

Jan

Re: [Xen-devel] xen-netback notify DomU to send ARP.

[jianhai luan]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

The patch main to fix the below circumstance:
Bonding  run in Active-Backup mode.
Out PC --> switcher
             port A --> eth0 --> bond0 --> xenbr0 --> netbackend --> DomU
             port B -- eth1 /
Or

Out PC (R)--> switcher A --> eth0 --> bond0 --> xenbr0 --> netbackend 
--> DomU
             \ switcher B -- eth1 /

When Switcher Port A (active port) don't reach, or switcher A don't reach,
the surroundings will changed to the below circumstance.
Out PC --> switcher
             port A -X- eth0 -- bond0 -- xenbr0 -- netbackend -- DomU
             port B -- eth1 /
Or

Out PC (R)--> switcher A -X- eth0 -- bond0 -- xenbr0 -- netbackend -- DomU
             \ switcher B -- eth1 /

So, the former traffic will be unreachable before find the correct path 
(by sending
ARP request).

So, the patch is main to found the bonding change event, and gratutious 
ARP initialtivly
to out PC find the correct path.

the correct path should be the below circumstance:
Out PC --> switcher
             port A -X- eth0 --> bond0 --> xenbr0 --> netbackend --> DomU
             port B --> eth1 /
Or

Out PC (R)--> switcher A -X- eth0 --> bond0 --> xenbr0 --> netbackend 
--> DomU
             \ switcher B --> eth1 /

Thanks,
Jason

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-xen-netback-notify-frontend-to-send-gratuitous-ARP.patch --]
[-- Type: text/plain; charset=gb18030; name="0001-xen-netback-notify-frontend-to-send-gratuitous-ARP.patch", Size: 3502 bytes --]

From cd5a33f9137a60f27c2a8c6c77a520d2df356c7a Mon Sep 17 00:00:00 2001
From: Jason Luan <jianhai.luan@oracle.com>
Date: Fri, 28 Dec 2012 15:43:06 +0800
Subject: [PATCH] xen-netback notify frontend to send gratuitous ARP.

In the real network environment, some cause will lead
to Active-Backup mode bonding chose new actived port.
After that, the trffic, destinated to DomU by inactived
port (former actived port), will be unreachable at now.
DomU should send gratutious ARP initialtivly to find the
new corrected path.

By netback's Connected->Connected transition, frontend
will watch the change, and send gratuitous ARP.

Signed-off-by: Jason Luan <jianhai.luan@oracle.com>
---
 drivers/net/xen-netback/xenbus.c |   68 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..ebea683 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,74 @@ 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);
 
+/*
+ * By Connected->Connected transition, netfront will watch the change and
+ * send gratuitous ARP.
+ */
+static void notify_front_arping(struct xenbus_device *dev)
+{
+	struct xenbus_transaction xbt;
+	int err;
+
+	if (xenbus_read_driver_state(dev->nodename) != XenbusStateConnected)
+		return;
+
+again:
+	err = xenbus_transaction_start(&xbt);
+	if (err) {
+		pr_fmt("Error starting transaction");
+		return;
+	}
+
+	err = xenbus_printf(xbt, dev->nodename, "state", "%d", dev->state);
+	if (err) {
+		pr_fmt("Error writing the state");
+		goto abort;
+	}
+
+	err = xenbus_transaction_end(xbt, 0);
+	if (err == -EAGAIN)
+		goto again;
+	if (err)
+		pr_fmt("Error ending transaction");
+
+	return;
+abort:
+	xenbus_transaction_end(xbt, 1);
+}
+
+#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 = 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)
+		return NOTIFY_DONE;
+
+	switch (event) {
+	case NETDEV_NOTIFY_PEERS:
+		/* Notify frontend to Send gratuitous ARP */
+		notify_front_arping(be->dev);
+		break;
+	}
+
+	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 +193,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:
-- 
1.7.6.5

Re: [V2] xen-netback notify DomU to send ARP.

[Jason Luan]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

于 2013年01月21日 20:23, Ian Campbell 写道:
> Which Linux did you test? pvops or something based on the classic-Xen
> patches?
>
> On Mon, 2013-01-21 at 11:55 +0000, Jan Beulich wrote:
>>>>> On 21.01.13 at 08:26, jianhai luan <jianhai.luan@oracle.com> wrote:
>>> +static void notify_front_arping(struct xenbus_device *dev)
>>> +{
>>> +	int err;
>>> +
>>> +	if (dev->state != XenbusStateConnected)
>>> +		return;
>>> +
>>> +	err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%d", dev->state);
>>> +	if (err) {
>>> +		pr_fmt("Error writing the state");
>> What's this? pr_fmt() alone makes no sense at all, and I'd be
>> pretty surprised if the compiler didn't warn about this construct.
>>
>> Further, you probably want to say "re-writing" and include the
>> error code in the message. And of course you want a \n at the
>> end.
>>
>> Finally - no need for the braces ...
>>
>>> +	}
>>> +
>>> +	return;
>> ... nor this "return".
> Agreed on all counts.
>
> Jason, when you resend with these fixes please CC the netdev list and
> folks listed by ./scripts/get-maintainers.pl for the patch.
>
> Ian.

Thank you for your notifying.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


Thanks,
Jason

[-- Attachment #2: 0001-xen-netback-notify-frontend-to-send-gratuitous-ARP.patch --]
[-- Type: text/x-patch, Size: 3130 bytes --]

>From a1acd31b9672d1000549e71a9467b71b1c229d7d Mon Sep 17 00:00:00 2001
From: Jason Luan <jianhai.luan@oracle.com>
Date: Fri, 28 Dec 2012 15:43:06 +0800
Subject: [PATCH] xen-netback notify frontend to send gratuitous ARP.

In the real network environment, some cause will lead
to Active-Backup mode bonding chose new actived port.
After that, the trffic, destinated to DomU by inactived
port (former actived port), will be unreachable at now.
DomU should send gratutious ARP initialtivly to find the
new corrected path.

By netback's Connected->Connected transition, frontend
will watch the change, and send gratuitous ARP.

Signed-off-by: Jason Luan <jianhai.luan@oracle.com>
---
 drivers/net/xen-netback/xenbus.c |   48 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..844fd86 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,54 @@ 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);
 
+/*
+ * By Connected->Connected transition, netfront will watch the change and
+ * send gratuitous ARP.
+ */
+static void notify_front_arping(struct xenbus_device *dev)
+{
+	int err;
+
+	if (dev->state != XenbusStateConnected)
+		return;
+
+	err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%d", dev->state);
+	if (err)
+		pr_warn("NetBack: Failure to notify DomU (err=%d)\n", err);
+}
+
+#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 = 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)
+		return NOTIFY_DONE;
+
+	switch (event) {
+	case NETDEV_NOTIFY_PEERS:
+		/* Notify frontend to Send gratuitous ARP */
+		notify_front_arping(be->dev);
+		break;
+	}
+
+	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 +173,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:
-- 
1.7.9.5


[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel