Re: [Xen-devel] [xen-4.0-testing test] 2045: regressions - FAIL

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Tue, 2010-08-31 at 19:11 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-4.0-testing test] 2045: 
> regressions - FAIL"):
> > On Tue, 2010-08-31 at 15:35 +0100, Ian Jackson wrote:
> > > [Ian C:]
> > > > did this by adding
> > > >         net.ipv4.conf.default.arp_notify = 1
> > > > to /etc/sysctl.conf and that seemed to do the trick.
> > > 
> > > I think this is a bug.  I think the default should be for something to
> > > send this gratuitous arp and the most logical answer in the PV or
> > > PV-on-HVM case is the domU.
> > 
> > This is the upstream default, not something we control directly from
> > netfront etc.
> 
> Um, I'm not sure I follow.  The situation when we need to do
> gratuitous arp is after save/restore or migration.  This is somewhat
> analogous to hibernation/suspend, except that hibernation/suspend
> pretty much assumes that the system was previously not running, not
> previously on a different switch port etc.
> 
> Perhaps netfront needs to do something special.

When netfront was upstreamed we were asked to remove the explicit
gratuitous ARP sending code from the driver and to instead use the
network stack provided functionality -- this is the arp_notify hooks
which we already call as appropriate from netfront but as I said it is
disabled upstream by default.

It's possible that someone should have a go at upstreaming a patch to
enable arp_notify by default or to make notifications triggered by
netif_notify_peers() not gate on the arp_notify sysctl or something.
like that. I don't think just enabling arp_notify by default will fly --
there are other triggers for that path such as interfaces coming up.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel