svn commit: r295136 - in head: sys/kern sys/netinet sys/sys usr.bin/netstat

[Alfred Perlstein]

On 2/2/16 12:23 PM, Xin LI wrote:
>
>
> On Tuesday, February 2, 2016, Alfred Perlstein <alfred at freebsd.org 
> <mailto:alfred at freebsd.org>> wrote:
>
>
>
>     On 2/2/16 11:39 AM, John Baldwin wrote:
>
>         On Tuesday, February 02, 2016 05:57:59 AM Alfred Perlstein wrote:
>
>             Author: alfred
>             Date: Tue Feb  2 05:57:59 2016
>             New Revision: 295136
>             URL: https://svnweb.freebsd.org/changeset/base/295136
>
>             Log:
>                Increase max allowed backlog for listen sockets
>                from short to int.
>                   PR: 203922
>                Submitted by: White Knight <white_knight at 2ch.net>
>                MFC After: 4 weeks
>
>         You do realize that this breaks the ABI of the sysctls used to
>         fetch
>         connection lists (and so will break existing binaries like
>         ucd-snmpd, etc.)
>         and thus can't be MFC'd right?
>
>     OK, I will not MFC it.
>
>     Is it worthwhile to extend the xsocket to have padding so that in
>     11.x and beyond we can allow for some changes in the structure?
>
>     Another idea I had was to include a version number with the sysctl
>     request so that we can send back versioned structures, let me know
>     what you think about that.
>
>     The first idea will take not more than a few days for me to
>     accomplish, the second (versioning the sysctl) probably a few more
>     days than that.
>
>
> We have similar construction (versioned ioctl) in FreeBSD ZFS but the 
> main goal is to keep system bootable, not to support all 
> functionalities.  Do we change the structure often and is it important 
> enough to warrant the complexity?  I think kmem interface have a 
> simple size check to guard against world/kernel inconsistency.
>
> I would second John's comment on the necessity of the change though, 
> if one already have 32K of *backlogged* connections, it's probably not 
> very useful to allow more coming in.  It sounds like the application 
> itself is seriously broken, and unless expanding the field have some 
> performance benefit, I don't think it should stay.

Imagine a hugely busy image board like 2ch.net, if there is a single 
hiccup, it's very possible to start dropping connections.

I stand by the scalability improvement offered here even though it is an 
edge case.  Linux appears to offer 32 bits of backlog and so should we.

-Alfred