Re: resolving routes externally
From: Bruce M Simpson (bms_at_spc.org)
Date: 11/23/04
- Previous message: Sam Leffler: "Re: FAST_IPSEC vs IPSEC performanc"
- In reply to: Martin Eugen: "resolving routes externally"
- Next in thread: James: "Re: resolving routes externally"
- Reply: James: "Re: resolving routes externally"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 23 Nov 2004 10:36:46 -0800 To: Martin Eugen <martin.eugen@gmail.com>
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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
- Previous message: Sam Leffler: "Re: FAST_IPSEC vs IPSEC performanc"
- In reply to: Martin Eugen: "resolving routes externally"
- Next in thread: James: "Re: resolving routes externally"
- Reply: James: "Re: resolving routes externally"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
