Re: BUG: udp socket, getsockopt + setsockopt

Re: BUG: udp socket, getsockopt + setsockopt

[David Ashley]

I forgot to mention it doesn't act the same on my x86 desktop running
linux. I don't recall what version. On my pc there is no trouble.
Oh well.

Thanks--
Dave

>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

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: BUG: udp socket, getsockopt + setsockopt

[Val Henson]

I'm not sure what version this change appeared.  Also, your pc may
have different default socket size settings.  This command will show
you both the max and default settings:

cat /proc/sys/net/core/?mem_*

(You can also set them in the usual way.)

-VAL

On Tue, Jan 29, 2002 at 07:26:56PM -0800, David Ashley wrote:
>
> I forgot to mention it doesn't act the same on my x86 desktop running
> linux. I don't recall what version. On my pc there is no trouble.
> Oh well.
>
> Thanks--
> Dave
>
> >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
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: BUG: udp socket, getsockopt + setsockopt

[David Ashley]

That's not getting set anywhere, the socket code is really small, just
like a textbook example. The man page says that is read only...

-Dave

>This is just a guess, but is SO_RCVLOWAT getting set somewhere?  The receive
>call will block until it gets the number of bytes set with this option.  I
>think it defaults to 1, so it should normally return when any data is
>available on the socket.  But if it has been bumped up to a big number, it
>might account for the behavior you're seeing.
>
>-Josh

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

BUG: udp socket, getsockopt + setsockopt

[David Ashley]

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/

Re: BUG: udp socket, getsockopt + setsockopt

[Josh Horvath]

This is just a guess, but is SO_RCVLOWAT getting set somewhere?  The receive
call will block until it gets the number of bytes set with this option.  I
think it defaults to 1, so it should normally return when any data is
available on the socket.  But if it has been bumped up to a big number, it
might account for the behavior you're seeing.

-Josh

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/

Re: BUG: udp socket, getsockopt + setsockopt

[Val Henson]

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/