Date: Wed, 3 Oct 2012 13:06:11 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: freebsd@chrysalisnet.org, freebsd-current@freebsd.org, Gleb Smirnoff <glebius@freebsd.org> Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? Message-ID: <CAJ-VmomZDhJpvj0VjFbzvXDOVzT2goC%2Bp5GULDap1V=2d%2Bf3zg@mail.gmail.com> In-Reply-To: <CAGH67wRY6cJkVRTzQ_QMt=a0F%2Bk9oyVUs_tyOAsY5ZbUaRySDA@mail.gmail.com> References: <03e101cda197$326dc240$974946c0$@org> <CAGH67wRY6cJkVRTzQ_QMt=a0F%2Bk9oyVUs_tyOAsY5ZbUaRySDA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 October 2012 13:01, Garrett Cooper <yanegomi@gmail.com> wrote:
>
> Here's where it's being held at 65535 (sys/kern/kern_uipc.c):
>
> 3276 static int
> 3277 sysctl_somaxconn(SYSCTL_HANDLER_ARGS)
> 3278 {
> 3279 int error;
> 3280 int val;
> 3281
> 3282 val = somaxconn;
> 3283 error = sysctl_handle_int(oidp, &val, 0, req);
> 3284 if (error || !req->newptr )
> 3285 return (error);
> 3286
> 3287 if (val < 1 || val > USHRT_MAX)
> 3288 return (EINVAL);
> 3289
>
> More details about the need for this limit are in
> http://svnweb.freebsd.org/base?view=revision&revision=140730 .
>
> It looks like this needs to be enhanced to support more than
> USHRT_MAX, which will require socket structure changes and other fun
> things, but should be possible... I've CCed glebius for comment on
> this.
Again, somaxconn is _not the number of sockets_. It's the backlog
allowed in the incoming connection queue for a given socket. That's
it.
If you pass listen a backlog value of -1 or greater than somaxconn,
then the queue depth gets pinned at somaxconn.
There's something else going on..
Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomZDhJpvj0VjFbzvXDOVzT2goC%2Bp5GULDap1V=2d%2Bf3zg>