From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 23 18:36:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74E6216A4CE; Tue, 23 Nov 2004 18:36:51 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEC6A43D39; Tue, 23 Nov 2004 18:36:50 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id E1DC5653D2; Tue, 23 Nov 2004 18:36:48 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 51694-01-4; Tue, 23 Nov 2004 18:36:48 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id F0B4E65375; Tue, 23 Nov 2004 18:36:47 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 350406680; Tue, 23 Nov 2004 10:36:46 -0800 (PST) Date: Tue, 23 Nov 2004 10:36:46 -0800 From: Bruce M Simpson To: Martin Eugen Message-ID: <20041123183646.GB733@empiric.icir.org> Mail-Followup-To: Martin Eugen , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <966ba91e04112301052fed8d6b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <966ba91e04112301052fed8d6b@mail.gmail.com> cc: freebsd-net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: resolving routes externally X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 18:36:51 -0000 On Tue, Nov 23, 2004 at 11:05:06AM +0200, Martin Eugen wrote: > At the beginning my intention was to use the routing sockets > mechanisms, and say, to issue a 'missing route' message to some > userland daemon capable of resolving those complex addresses (the > resolving mechanism is generally a lookup in a local DB). But then I You're on the right track here. You might also wish to investigate the RTM_RESOLVE mechanism. > realized there is no (Am I missing it?) code in the routing modules > that could make the thread handling the packet sleep until the > userland daemon is looking up the route. (I'm also still not sure if a > 'netisr' thread is safe to sleep?) So I started to look at the ARP > code, but it of course lacks the kernel - userland communication > interface. I would appreciate any ideas about what would be the easier > way to implement such a thing where the kernel could wait (up to some > reasonable time-out) a userland daemon to install a new route. If I understand correctly, you want the kernel to queue packets until layer 2 address resolution is complete. Right now we don't do this. If there is no route to a destination, packets will be dropped. The ARP code implements a queue for each IP host address which is exactly 1 mbuf long (see llinfo_arp->la_hold). This holds the most recent packet that the host is attempting to transmit to the host pending MAC address lookup. All other packets will be dropped. Making a network stack thread sleep would be a Very Bad Idea. A more appropriate approach would be to use a separate netisr queue for packets which have pending external MAC address lookup. However, rather than calling netisr_dispatch() directly, you would want to call schednetisr() directly once the route resolution was complete. I guess this is non-IP traffic, in which case making the modifications which you need will probably be easier. Regards, BMS