From: Val Henson <val@nmt.edu>
To: David Ashley <dash@xdr.com>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: BUG: udp socket, getsockopt + setsockopt
Date: Tue, 29 Jan 2002 17:05:48 -0700 [thread overview]
Message-ID: <20020129170548.J2050@boardwalk> (raw)
In-Reply-To: <200201291649.g0TGn2x09346@xdr.com>; from dash@xdr.com on Tue, Jan 29, 2002 at 08:49:02AM -0800
When you set SO_RCVBUF with setsockopt, the kernel allocates twice the
memory you set. This has something to do with BSD compatibility and
storing internal kernel structures in the memory allocated for the
recv buf. Try getsockopt after you setsockopt.
This is ostensibly a feature, not a bug. Search the linux-kernel
archives for "so_rcvbuf" and "David Miller". Hint: you probably won't
convince Dave to change his mind.
-VAL
On Tue, Jan 29, 2002 at 08:49:02AM -0800, David Ashley wrote:
>
> I've found a very strange bug in linux ppc 2.4.17, I think. I'm pulling
> udp packets off the LAN and reading them in a user space program. They come
> in sets of about 60k bytes all together, then pause for a while. I only can
> read the first 48k successfully, then they get lost.
>
> If I have a setsockopt call on the socket, setting SO_RCVBUF to 65535,
> then I don't lose any data. But if I do a getsockopt beforehand on
> SO_RCVBUF, it reports 65535. Without the setsockopt I get the packet loss,
> with it I don't lose any. It is strange because the value doesn't appear
> to be changing.
>
> What can be causing this mysterious behaviour?
>
> -Dave
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-01-30 0:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-29 16:49 BUG: udp socket, getsockopt + setsockopt David Ashley
2002-01-29 16:58 ` Josh Horvath
2002-01-30 0:05 ` Val Henson [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-01-30 3:22 David Ashley
2002-01-30 3:26 David Ashley
2002-01-30 3:41 ` Val Henson
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=20020129170548.J2050@boardwalk \
--to=val@nmt.edu \
--cc=dash@xdr.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
/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;
as well as URLs for NNTP newsgroup(s).