On 2/2/16 12:23 PM, Xin LI wrote:
On Tuesday, February 2, 2016, Alfred Perlstein <alf...@freebsd.org
<mailto:alf...@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_kni...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
