Date: Tue, 23 Nov 2004 10:36:46 -0800 From: Bruce M Simpson <bms@spc.org> To: Martin Eugen <martin.eugen@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: resolving routes externally Message-ID: <20041123183646.GB733@empiric.icir.org> In-Reply-To: <966ba91e04112301052fed8d6b@mail.gmail.com> References: <966ba91e04112301052fed8d6b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041123183646.GB733>