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] [xen-4.0-testing test] 2045: regressions - FAIL

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.


Xen-devel mailing list