From: David Miller <davem@davemloft.net>
To: johunt@akamai.com
Cc: edumazet@google.com, arnd@arndb.de, soheil@google.com,
willemb@google.com, pabeni@redhat.com,
linux-arch@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [RFC PATCH] sock: add SO_RCVQUEUE_SIZE getsockopt
Date: Mon, 13 Mar 2017 12:39:33 -0700 (PDT) [thread overview]
Message-ID: <20170313.123933.1813218797817423920.davem@davemloft.net> (raw)
In-Reply-To: <522a2e2d-c288-7019-3f12-2b624d6aa921@akamai.com>
From: Josh Hunt <johunt@akamai.com>
Date: Mon, 13 Mar 2017 12:38:39 -0500
> On 03/13/2017 11:12 AM, Eric Dumazet wrote:
>> On Mon, Mar 13, 2017 at 8:59 AM, Josh Hunt <johunt@akamai.com> wrote:
>>> Allows application to read the amount of data sitting in the receive
>>> queue.
>>>
>>> Signed-off-by: Josh Hunt <johunt@akamai.com>
>>> ---
>>>
>>> A team here is looking for a way to get the amount of data in a UDP
>>> socket's
>>> receive queue. It seems like this should be SIOCINQ, but for UDP
>>> sockets that
>>> returns the size of the next pending datagram. I implemented the patch
>>> below,
>>> but am wondering if this is the right place for this change? I was
>>> debating
>>> between this or a new UDP ioctl.
>>
>> But what is the 'amount of data' exactly ?
>> Number of packets, amount of bytes to read from these packets ?
>
> I meant bytes. I will clarify in the next version.
As Eric is hinting, the calculation you are using doesn't represent
this.
You need to do something like walk the receive queue and add the
skb->len values together.
sk->sk_rmem_alloc is usually much larger than the sum of the skb->len
values in the socket receive queue. I don't see how this culmination
of skb->truesize values is useful, whereas I can see how an application
could want the summation of the skb->len values.
next prev parent reply other threads:[~2017-03-13 19:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-13 15:59 [RFC PATCH] sock: add SO_RCVQUEUE_SIZE getsockopt Josh Hunt
2017-03-13 15:59 ` Josh Hunt
2017-03-13 16:12 ` Eric Dumazet
2017-03-13 16:12 ` Eric Dumazet
2017-03-13 17:38 ` Josh Hunt
2017-03-13 17:38 ` Josh Hunt
2017-03-13 19:39 ` David Miller [this message]
2017-03-13 23:34 ` Josh Hunt
2017-03-13 23:34 ` Josh Hunt
2017-03-14 0:10 ` David Miller
2017-03-14 22:11 ` Josh Hunt
2017-03-14 1:31 ` Eric Dumazet
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=20170313.123933.1813218797817423920.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=arnd@arndb.de \
--cc=edumazet@google.com \
--cc=johunt@akamai.com \
--cc=linux-arch@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=soheil@google.com \
--cc=willemb@google.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;
as well as URLs for NNTP newsgroup(s).