Re: sysctl kern.ipc.somaxconn limit 65535 why?

Hi,

On Wed, Jan 4, 2012 at 3:22 PM, Dan The Man <dan_at_sunsaturn.com> wrote:
>
>
> sunsaturn:~# sysctl -w kern.ipc.somaxconn=200000
> kern.ipc.somaxconn: 4096
> sysctl: kern.ipc.somaxconn: Invalid argument
> sunsaturn:~# sysctl -w kern.ipc.somaxconn=65536
> kern.ipc.somaxconn: 4096
> sysctl: kern.ipc.somaxconn: Invalid argument
> sunsaturn:~# sysctl -w kern.ipc.somaxconn=65535
> kern.ipc.somaxconn: 4096 -> 65535
> sunsaturn:~#
>
> Trying to stress test a framework here that tosses 100k of connections into
> a listen queue before doing anything, I realize I'll have to use multiple
> local IPs get get around port limitations, but why is this backlog using a
> limit?
>
This is an arbitrary implementation limitation. A bit of code
archaeology reveals that the explicit limitation was introduced in
1,226 of kern/uipc_socket.c[0]. Quoting the commit log:

glebus_at_
<<
- Convert so_qlen, so_incqlen, so_qlimit fields of struct socket from
  short to unsigned short.
- Add SYSCTL_PROC() around somaxconn, not accepting values < 1 or > U_SHRTMAX.

Before this change setting somaxconn to smth above 32767 and calling
listen(fd, -1) lead to a socket, which doesn't accept connections at all.

Reviewed by:	rwatson
Reported by:	Igor Sysoev
>>

so the limited width of some `struct socket' fields enforces this
limitation. Now, the reason for `so_qlen', `so_incqlen', `so_qlimit'
to be so limited might be lost in the arcane of time. After all "640K
ought to be enough for anyone", doesn't it ?

 - Arnaud

[0]: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c#rev1.226



>
> Dan.
>
>
> --
> Dan The Man
> CTO/ Senior System Administrator
> Websites, Domains and Everything else
> http://www.SunSaturn.com
> Email: Dan_at_SunSaturn.com
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"