[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