Date: Mon, 7 Jul 2008 13:04:24 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet udp_usrreq.c Message-ID: <20080707130242.Y63144@fledge.watson.org> In-Reply-To: <48720552.9000605@freebsd.org> References: <200807071057.m67Av9WD014167@repoman.freebsd.org> <20080707121042.W63144@fledge.watson.org> <48720552.9000605@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Jul 2008, Andre Oppermann wrote: > Caching the route in the inpcb has a number of problems: > > - any routing table change has to walk all inpcb's to invalidate > and remove outdated and invalid references. > > - adding host routes again just bloats the table again and makes > lookups more expensive. > > - host routes (cloned) do not change when the underlying route is > adjusted and packets are still routed to the old gateway (for > example new default route). > > - We have a tangled mess of cross-pointers and dependencies again > precluding optimizations to the routing table and code itself. The move towards read-write locking in UDP also complicates inpcb route caching, as there is no longer a guarantee that there's exclusive access to the inpcb in udp_output() and ip_output() -- the lock passed down may be a read lock, in which case a cached route can be used if appropriate, but not replaced if it's not the right one or otherwise inappropriate. This particular issue won't affect TCP for the forseeable future as it almost universally uses write locking on the inpcb. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080707130242.Y63144>