RFC: per-socket statistics on received/dropped packets

For a while I've been wanting a way for a program to find out if any of its
socket buffers were overflowing due to too much incoming traffic.  Finally, I
decided to code it up and try it out.

As it turns out, it was relatively simple to add, although it required the
addition of two new entries in sockios.h.

Basically, inside of sock_queue_rcv_skb() and sock_queue_err_skb() the receive
counter gets incremented unconditionally, and then if there is no free space in
the socket buffer then we also increment the counter for messages dropped due to
out of memory.

The stats are stored as part of a socket_stats struct, making it easy to add
other counters in the future.

To access and reset the counters, two ioctl commands were added to the socket
ioctl. GIOCSOCKSTATS is used to get the stats, while SIOCZEROSOCKSTATS is used
to reset them.  I haven't bothered with trying to reset them both atomically as
I don't think it's that critical.

The patch was coded and tested for 2.4.18, but it is known to at least apply
(with offsets) on 2.5.20.

Feel free to bash on it a bit, once the issues are worked out I'll submit to the
appropriate maintainer.

Chris
 
-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Your idea is totally useless for non-datagram sockets.
Only datagram sockets use the interfaces where you bump
the counters.

I don't like the patch, nor the idea behind it, at all.

"David S. Miller" wrote:

Your idea is totally useless for non-datagram sockets.
Only datagram sockets use the interfaces where you bump
the counters.

I don't like the patch, nor the idea behind it, at all.

Thanks for the feedback.

I buy the point about it only making sense for datagram sockets in its current
form.  Thus it would maybe make more sense to use udp_ioctl() rather than in the
generic socket ioctl.

However, what do you have against the basic idea of a program knowing how many
packets have 
been dropped on its sockets?  I added the feature to try and figure out where
packets were being dropped in an app I am developing, and so far its been very
useful.

More generally, is there a generic place that I could tie into for the counter
increment that would work for all sockets?  While tcp would automatically handle
the dropped packets, it might be useful to know how many there were.

Thanks,

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Datagram sockets are the ones that drop data though (tcp will
deal with it via re-transmits).

I have not looked at his patch in detail, but I would welcome anything
that gets us closer to being able to account for every packet that enters
the NIC, or enters the kernel from user-space via send(to), etc...

David S. Miller wrote:

Your idea is totally useless for non-datagram sockets.
Only datagram sockets use the interfaces where you bump
the counters.

I don't like the patch, nor the idea behind it, at all.

-- 
Ben Greear [off-list ref]       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear