Re: [RFC PATCH] sock: add SO_RCVQUEUE_SIZE getsockopt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/13/2017 02:39 PM, David Miller wrote:
From: Josh Hunt <johunt@xxxxxxxxxx>
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@xxxxxxxxxx> wrote:
Allows application to read the amount of data sitting in the receive
queue.

Signed-off-by: Josh Hunt <johunt@xxxxxxxxxx>
---

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.


In this particular case they really do want to know total # of bytes in the receive queue, not the data bytes they can consume from an application pov. The kernel currently only exposes this value through netlink or /proc/net/udp from what I saw.

I believe Eric's suggestion in his previous mail was to export all of these meminfo metrics via a single socket option call similar to how its done in netlink. We could then use that for both call sites.

I agree that it would be useful to also have the data you and Eric are suggesting exposed somewhere, the total # of skb->len bytes sitting in the receive queue. I could add that as a second socket option.

Does this sound reasonable?

Josh



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux