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 31.08.10 at 17:05, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Tue, 2010-08-31 at 15:35 +0100, Ian Jackson wrote:
>> > Even with the fix in place the gratuitous ARP behaviour is disabled
>> by
>> > default so you need to enable the net.ipv4.conf.<dev>.arp_notify
>> sysctl
>> > for any device you want to send the notifications. When I was
>> testing I
>> > 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.

Wouldn't it seem possible/reasonable to force this on from netfront
(via IN_DEV_CONF_SET()) at least until upstream possibly decides
to not let the ARP_NOTIFY sysctl control the sending of an ARP
explicitly requested through netif_notify_peers()?

The perhaps undesirable effect of this (as well as setting the sysctl
through /etc/sysctl.conf) is that it doesn't only control the ARP we
want sent, but also one when bringing the interface up or changing
its address, so I'd still favor moving the NETDEV_NOTIFY_PEERS
case past the "if (IN_DEV_ARP_NOTIFY(in_dev))" in inetdev_event().
Have you got any feedback from Linux folks on such a potential


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Xen-devel] [xen-4.0-testing test] 2045: regressions - FAIL, Jan Beulich <=