[Bug 204438] setsockopt() handling of kern.ipc.maxsockbuf limit
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Thu Nov 12 19:33:05 UTC 2015
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204438
--- Comment #15 from Alfred Perlstein <alfred at FreeBSD.org> ---
> Re (1) do you mean that when kern.ipc.maxsockbuf gets set, scale the sb_max value up by the inverse of sb_max_adj? ie, kern.ipc.maxsockbuf * 2304 / 2048. In that case, setting kern.ipc.maxsockbuf to 1000000 bytes would actually set sb_max to 1125000 (and sb_max_adj to 1000000), making it possible to set the buffers to 1000000 bytes.
I think so. However just to be clear, let's not have a sysctl that has the
following behavior:
% sysctl kern.ipc.maxsockbuf=1000000
% sysctl kern.ipc.maxsockbuf
kern.ipc.maxsockbuf=1125000
$
We probably want this:
% sysctl kern.ipc.maxsockbuf=1000000
% sysctl kern.ipc.maxsockbuf
kern.ipc.maxsockbuf=1000000
$ sysctl kern.ipc.maxsockbufmeta
kern.ipc.maxsockbufmeta=1125000
> Re (2), If kern.ipc.maxsockbufmeta were read/write, which of the settings would have precedence? Would you have to set maxsockbufmeta first anytime you wanted to set maxsockbuf? Or would setting maxsockbuf auto-set maxsockbufmeta?'
I think having them auto-set each other would be the most user friendly option.
> Re Linux silent truncation: agreed, it's scary and gives the impression that setsockopt() worked, when really it didn't do anything at all
Yes. It would be a good idea to hop on a Linux kernel IRC channel/mailing list
and ask them. Last time I did this I got some pretty useful information which
changed my world view.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-net
mailing list