From owner-freebsd-net@FreeBSD.ORG Sun Jan 4 21:04:42 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93CE23FD; Sun, 4 Jan 2015 21:04:42 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 5845964F94; Sun, 4 Jan 2015 21:04:41 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9D07E7300A; Sun, 4 Jan 2015 22:09:19 +0100 (CET) Date: Sun, 4 Jan 2015 22:09:19 +0100 From: Luigi Rizzo To: current@freebsd.org, net@freebsd.org, tegge@freebsd.org Subject: BOOTP_SETTLE_DELAY in sys/nfs/bootp_subr.c ? Message-ID: <20150104210919.GA22198@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 21:04:42 -0000 [I realize this is code from 15 years ago so i am not sure if anyone still knows or remembers the answer] sys/nfs/bootp_subr.c is used to request via bootp or dhcp an address and a boot path. The negotiation is done in a loop, and apparently when replies are received on _all_ interfaces, the code extends the loop by another 3 seconds (BOOTP_SETTLE_DELAY) with a logic that is not documented and I do not follow. Any idea ? I would understand not stopping at the first reply in case we want to pick the 'best' one from multiple responses (which is implemented, to some degree, in bootpc_received() ). But if that is the case, one should either 1) use an unconditionally large timeout, or 2) take the first incoming packet (not necessarily valid) on _any_ interface as a signal that "ok this interface is now on" and apply the grace period from there. Why do i care ? I am booting a diskless kernel with bhyve and BOOTP_SETTLE_DELAY unnecessarily extends the boot time a lot, and even worse delays happen if you have multiple interfaces that do not respond due to some other unclear logic. Depending on what is the original intention i would like to implement either option #1 or #2 above. Also, I would like to use environment variables to set/override the in-kernel bootp settings cheers luigi