Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Dec 2012 10:06:07 -0800
From:      Vijay Singh <vijju.singh@gmail.com>
To:        Karim Fodil-Lemelin <fodillemlinkarim@gmail.com>
Cc:        freebsd-net@freebsd.org, Navdeep Parhar <nparhar@gmail.com>
Subject:   Re: use of V_tcbinfo lock for TCP syncache
Message-ID:  <CALCNsJRq2NLkybJSsPNRk1M%2Bxo-_nW_GYCmuM%2BSv_G35F7S8CQ@mail.gmail.com>
In-Reply-To: <50D338DB.5070907@gmail.com>
References:  <CALCNsJRFyQ9ZmfJ3quX2-cUuFHjs2rXw63Tq5ZH-uP1%2BoQmjLw@mail.gmail.com> <50D218BA.7080301@FreeBSD.org> <50D21C3B.8020803@gmail.com> <CALCNsJS8j0wvv4dc1Q6rLckmr0RE%2BgW0%2BmUDdmSvyfjXzKugsQ@mail.gmail.com> <50D24774.80800@gmail.com> <CALCNsJQHCk4m=MqXwK-ejfhD31JKHQxtP8Ycx_FyGsiutfvMdA@mail.gmail.com> <50D338DB.5070907@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> How do you plan to handle the fact that most of tcp_input() and
> tcp_do_segment() require at least a read lock held on the pcbinfo lock?

Yes, I realized that after some experiments yesterday.

> Is your goal to reduce the amount of code that gets executed under the write
> lock protection of pcbinfo or completely get rid of the lock all together?

While these are good goals, mine is simply to avoid making the socket
upcall with the pcbinfo lock held, due to peculiarities in my
environment.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALCNsJRq2NLkybJSsPNRk1M%2Bxo-_nW_GYCmuM%2BSv_G35F7S8CQ>