Date: Wed, 14 Mar 2007 08:31:20 -0400 From: "Keith Arner" <vornum@gmail.com> To: "Robert Watson" <rwatson@freebsd.org> Cc: net@freebsd.org Subject: Re: netisr_direct Message-ID: <8e552a500703140531l39f6fae5o518ee271b879eb1a@mail.gmail.com> In-Reply-To: <20070311073249.R20646@fledge.watson.org> References: <45C0CA5D.5090903@incunabulum.net> <45E6BEE0.2050307@FreeBSD.org> <45E6C22D.7060200@freebsd.org> <45E6D70C.10104@FreeBSD.org> <45EEB086.3050409@FreeBSD.org> <45F03269.7050705@FreeBSD.org> <45F08F1D.5080708@us.fujitsu.com> <20070310035135.B30274@fledge.watson.org> <8e552a500703102157p1845926au65bb3adaf81c01c0@mail.gmail.com> <20070311073249.R20646@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/11/07, Robert Watson <rwatson@freebsd.org> wrote:
>
>
> Yes -- right now the in-bound TCP path is essentially serialized because
> of
> the tcbinfo lock. The reason for this is that the tcbinfo lock doesn't
> just
> protect the inpcb chains during lookup, but also effectively acts as a
> reference to prevent the inpcb from being freed during input processing.
> There are several ways we could start to reduce contention on that lock:
>
So, why is the tcbinfo lock being used to protect the pcb from deletion?
Why isn't the INP_LOCK on the pcb used, instead?
Keith
--
Well, I didn't find the Holy Grail,
but I did find a rusty cup without too many holes in it...
-- Jeff Semke
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8e552a500703140531l39f6fae5o518ee271b879eb1a>