public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andries.Brouwer@cwi.nl
To: alan@lxorguk.ukuu.org.uk, davem@redhat.com,
	mbartz@optushome.com.au, torvalds@transmeta.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: setsockopt(..,SO_RCVBUF,..) sets wrong value
Date: Thu, 2 Aug 2001 14:38:43 GMT	[thread overview]
Message-ID: <200108021438.OAA110364@vlet.cwi.nl> (raw)

    From: "David S. Miller" <davem@redhat.com>

    Manfred Bartz writes:

     > When I do a setsockopt(..,SO_RCVBUF,..) and then read the value back
     > with getsockopt(), the reported value is exactly twice of what I set

    That's correct.  Please search the list archives to learn why things
    behave this way and why they are not going to change.

    I wish that this long winded, and often occurring thread not occur
    again.

Hmm. There are two aspects to this: explaining why "*2" is done,
and the fact that getsockopt() reports something other than
what was given to setsockopt().

The best way to prevent questions about the "*2" is to document it.
Below some text by Andi Kleen.

--- ../linux-2.4.7/linux/net/core/sock.c	Sat Jul 28 17:08:47 2001
+++ linux/net/core/sock.c	Thu Aug  2 16:23:53 2001
@@ -232,6 +232,8 @@
 				val = sysctl_wmem_max;
 
 			sk->userlocks |= SOCK_SNDBUF_LOCK;
+
+			/* For the "*2", see SO_RCVBUF below. */
 			sk->sndbuf = max(val*2,SOCK_MIN_SNDBUF);
 
 			/*
@@ -251,7 +253,18 @@
 				val = sysctl_rmem_max;
 
 			sk->userlocks |= SOCK_RCVBUF_LOCK;
-			/* FIXME: is this lower bound the right one? */
+
+			/* People regularly wonder whether the "*2" here
+			   is correct. Linux reserves half of the socket
+			   buffer for metadata (skbuff headers etc.)
+			   BSD doesn't do that. Most programs using
+			   SO_SNDBUF/SO_RCVBUF didn't expect this, because
+			   traditional BSD does not do metadata accounting,
+			   and on Linux they ended up with too small effective
+			   buffers. To fix this Linux always doubles the
+			   buffer internally to stay compatible.
+			   See also socket(7). */
+
 			sk->rcvbuf = max(val*2,SOCK_MIN_RCVBUF);
 			break;


Of course everybody will regard a system broken that has a getfoo()
that does not return what was given to setfoo().
No documentation will change that.
 
Andries

             reply	other threads:[~2001-08-02 14:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-02 14:38 Andries.Brouwer [this message]
2001-08-02 15:59 ` setsockopt(..,SO_RCVBUF,..) sets wrong value Richard B. Johnson
     [not found] <no.id>
2001-08-02 14:26 ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2001-08-02 10:34 Manfred Bartz
2001-08-02 13:12 ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200108021438.OAA110364@vlet.cwi.nl \
    --to=andries.brouwer@cwi.nl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbartz@optushome.com.au \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox