From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MXxca-00071y-HN for qemu-devel@nongnu.org; Mon, 03 Aug 2009 09:30:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MXxcU-0006pS-OQ for qemu-devel@nongnu.org; Mon, 03 Aug 2009 09:30:35 -0400 Received: from [199.232.76.173] (port=37489 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MXxcR-0006oW-JF for qemu-devel@nongnu.org; Mon, 03 Aug 2009 09:30:27 -0400 Received: from mail2.shareable.org ([80.68.89.115]:51143) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MXxcR-0002st-0t for qemu-devel@nongnu.org; Mon, 03 Aug 2009 09:30:27 -0400 Date: Mon, 3 Aug 2009 14:30:08 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] slirp: Read host DNS config on demand Message-ID: <20090803133008.GB23062@shareable.org> References: <1249089022.20690.11.camel@localhost.localdomain> <20090802074352.GB3339@redhat.com> <4A75483E.8000200@web.de> <9ae48b020908021908v123aa866g470b78477f369594@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ae48b020908021908v123aa866g470b78477f369594@mail.gmail.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ed Swierk Cc: Jan Kiszka , qemu-devel@nongnu.org, "Michael S. Tsirkin" Ed Swierk wrote: > On Sun, Aug 2, 2009 at 8:03 AM, Jan Kiszka wrote: > > IMHO, 10 s is below the user surprise threshold for a dynamically > > changing network link. Moreover, inotify does not exist on all platforms. > > > > Let's keep things simple for the first step, we could still further > > improve it later on. 10 s are already an improvement over the current > > infinite timeout. > > Right. The most common situation in which the DNS server address > changes is after you wake up your laptop and wait for it to connect to > a new network. DHCP itself can take several seconds to do its thing, > so you're unlikely to notice the up-to-10-second delay before full > network connectivity is restored in a VM. I strongly disagree. Usual practice is to watch the NetworkManager icon until it indicates that DHCP is complete with a green light, finger poised over the clicking button, and then expect web browsing and SSH to work immediately after the green light appears. A 10 second delay at that point would be most irritating. Ideally, that's what RTNETLINK events are for: you can register for asynchronous events whenever a network interface is reconfigured, and trigger things like rereading /etc/resolv.conf from that. Windows has a similar mechanism for watching interface changes. But a 1/2 second delay would be fine. > Of course there's nothing magical about 10 seconds. A shorter timeout > would be even nicer, and I doubt anyone would really miss the CPU > cycles lost to re-reading a tiny text file, but I don't think > instantaneous response is required here. All you need is to call stat() to confirm that the file hasn't changed. Just check the dev/ino/mtime/size. If that were a periodic 1 second timer, the biggest cost on a laptop might be power drain due to CPU wakeups. But since the resolv.conf check should only should be done in reaction to the VM actively doing a DNS query (plus 1 second has passed since the last resolve.conf check), the CPU is already woken up, so it's cheap. -- Jamie