On 03/13/2017 07:10 PM, David Miller wrote:
From: Josh Hunt <johunt@xxxxxxxxxx>
Date: Mon, 13 Mar 2017 18:34:41 -0500
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.
Can you explain in what way this is useful?
The difference between skb->len and skb->truesize is really kernel
internal implementation detail, and I'm trying to figure out why
this would be useful to an application.
First, it looks like my original patch was against an old kernel which
did not have the updated udp accounting code. Not sure how that
happened. Apologies for that. There's no need to add in the backlog, at
least for udp now, sk_rmem_alloc is all that is needed for my case.
The application here is interested in monitoring the amount of data in
the receive buffer. Looking for and identifying overflows, and also
understanding how full it is. I know we already have SO_RXQ_OVFL, but
this only shows the # of drops on overflow.
We expose this (skmem) information via /proc and netlink today. It seems
like unnecessary overhead to require an application to also create a
netlink socket to get this data.
Creating a socket option to mimic the behavior of
sock_diag_put_meminfo() and export all meminfo_vars would be great if
that's something you'd accept.
Josh
