deprecation policy (Was: sysctl kern.ipc.somaxconn limit 65535 why?)

Vadim Goncharov vadim_nuclight at mail.ru
Tue Oct 9 09:32:05 UTC 2012


Hi Jeremie Le Hen! 

On Mon, 8 Oct 2012 12:49:34 +0200; Jeremie Le Hen wrote about 'Re: sysctl kern.ipc.somaxconn limit 65535 why?':

>> On 03.10.2012 22:03, Adrian Chadd wrote:
>>>
>>> somaxconn is the connection queue depth. If it's sitting at a couple
>>> hundred thousand then something else is going crazily wrong.
>>>
>>> I understand your frustration, but there's a lot of instances where
>>> the application just isn't doing things "right" and the OS tries to
>>> hide it as much as psosible. Blowing out somaxconn to chew up a whole
>>> lot of resources seems a bit silly. I'd rather investigate why the
>>> userland application is not servicing the connect queue often enough.
>>>
>>> I've written network services that supported tens of thousands of new
>>> TCP connections a second on a LAN and I never once had to bump
>>> somaxconn past 32767. I'm not saying that it won't apply to your
>>> scenario, I'm just trying to explain that there's likely more going
>>> on.
>> 
>> I guess the problem is rather kern.ipc.maxsockets which is only 25600.
>> 
>> The name somaxconn is confusing as it specifies the listen queue limit
>> instead of the maximum number of connections as the it suggests.

> If we want to change that name to something more sensible and less
> error-prone like "somaxbacklog", does the project has a policy to change
> sysctl names?

> I'm thinking of something like renaming the sysctl to "somaxbacklog" and
> make "somaxconn" compatibility shim during RELENG_10 which still works
> but prints a warning in the dmesg.

AFAIR, the policy was to keep for two major releases, not one, though it was
the policy for binaries, not sysctl (e.g. if /sbin/natd would be officially
made deprecated in 10.0 RELNOTES, then it must be kept in 10.* and 11.* with
complete removal in 12.0). Possibly the policy for sysctl's is the same,
because 3rd-party software may use such knobs, while not sure this applies to
kern.*, though.

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight at mail.ru
[Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]



More information about the freebsd-current mailing list