From: Eric Dumazet <dada1@cosmosbay.com>
To: Chris Friesen <cfriesen@nortel.com>
Cc: netdev@vger.kernel.org, Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: seeing strange values for tcp sk_rmem_alloc
Date: Tue, 01 Dec 2009 17:58:17 +0100 [thread overview]
Message-ID: <4B154B29.1030807@cosmosbay.com> (raw)
In-Reply-To: <4B15416A.2060202@nortel.com>
Chris Friesen a écrit :
> I'm hoping someone might be able to explain some odd behaviour that I'm
> seeing.
>
> Some of our developers wanted to be able to see how much of their rx
> socket buffer space was in use, so I added the following to sock_ioctl()
>
>
> case SIOCGSKRMEMALLOC:
> {
> int tmp;
> err = -EINVAL;
> if(!sock->sk)
> break;
> tmp = atomic_read(&sock->sk->sk_rmem_alloc);
> err = copy_to_user(argp, &tmp, sizeof(tmp));
> break;
> }
>
> To validate it, I wrote a testcase that opened a tcp socket, then looped
> sending 2k of data at a time to it and calling the above ioctl to check
> the sk_rmem_alloc value (without ever reading from the socket).
>
> The results were odd--I've copied them below. Can anyone explain how I
> can send 20K of data but sk_rmem_alloc still only shows 4.8K used, then
> it suddenly jumps by a lot on the next packet to something that more
> reflects reality, then repeats that pattern again? Is there some
> additional buffering happening somewhere in the TCP stack?
>
Me wondering why you think sk_rmem_alloc is about TX side.
Its used in RX path. rmem means ReadMemory.
You can send 1 Gbytes of data, and sk_rmem_alloc doesnt change, if your
TCP stream is unidirectionnal.
sk_rmem_alloc grows when skb are queued into receive queue
sk_rmem_alloc shrinks when application reads this receive queue.
next prev parent reply other threads:[~2009-12-01 16:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 16:16 seeing strange values for tcp sk_rmem_alloc Chris Friesen
2009-12-01 16:18 ` Chris Friesen
2009-12-01 16:58 ` Eric Dumazet [this message]
2009-12-01 17:28 ` Chris Friesen
2009-12-01 17:52 ` Eric Dumazet
2009-12-03 16:55 ` Chris Friesen
2009-12-03 17:04 ` Eric Dumazet
2009-12-03 21:40 ` Chris Friesen
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=4B154B29.1030807@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=cfriesen@nortel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.