I've noticed some issues with ephemeral port number selection from
tcp_connect(), which limit the number of concurrent, outgoing connections
that can be established (connect(), rather than accept()). Sifting through
the source code, I believe the issuess stem from two problems in the
tcp_connect()
> Date: Sat, 01 Dec 2012 09:28:05 +0100
> From: Andre Oppermann
>
> On 30.11.2012 15:09, Keith Arner wrote:
>> I've noticed some issues with ephemeral port number selection from
>> tcp_connect(),
>
> this is an excellent analysis. Could you please file it as
I'm trying to make sense out of the use of the variable "writable"
in the function m_pulldown(). In particular, how writable is used
on the line:
if ((off == 0 || offp) && len <= n->m_len - off && writable)
goto ok;
If the first two conditions in this test (off/offp and len) hold true,
On 3/9/07, Robert Watson <[EMAIL PROTECTED]> wrote:
It also introduces
parallelism in the in-bound network layer processing path by allowing
processing to occur in more than one thread at a time. However, you can
see
From the experimentation I've done, it seems that for TCP loads at least
On 3/11/07, Robert Watson <[EMAIL PROTECTED]> 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 preve
On 3/11/07, Robert Watson <[EMAIL PROTECTED]> wrote:
There are several ways we could start to reduce contention on that lock:
(3) Move towards greater granularity of locking for the tcbinfo: instead
of
a single mutex, move to more than one locks, so that different
connections
process
