Author: Chris Friesen <cfriesen@xxxxxxxxxxxxxxxxxx>
Date: Thu, 06 Jun 2002 15:37:28 -0400
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 tu
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.
Author: Chris Friesen <cfriesen@xxxxxxxxxxxxxxxxxx>
Date: Fri, 07 Jun 2002 11:34:35 -0400
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
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
Outside of the specific changes suggested by Chris, I can see a requirement to be able to detect poor connections. While TCP/IP may not drop packets from the perspective of user space applications, T
You guys we have SNMP statistics for these events, there is no reason to have them per-socket. You cannot convince me that when you are diagnosing a problem the SNMP stats are not enough to show you
David S. Miller wrote: You guys we have SNMP statistics for these events, there is no reason to have them per-socket. You cannot convince me that when you are diagnosing a problem the SNMP stats are
Why not? If you know where the drops are occurring, what else do you need to know? I'm not talking about per-socket SNMP counters, that would be rediclious.
Author: Pekka Pietikäinen <Pekka.Pietikainen@xxxxxxxx
Date: Sun, 9 Jun 2002 17:47:40 +0300
Have you guys checked out if the TCP_INFO getsockopt() would work for your needs? (obviously, it'll only work for TCP connections ). It gives you quite a bit of detail about what's happening in your
David S. Miller wrote: From: Ben Greear <greearb@xxxxxxxxxxxxxxx> Date: Sat, 08 Jun 2002 17:13:35 -0700 If you're talking per-socket SNMP counters, then that could work. General protocol-wide counter
From: Ben Greear <greearb@xxxxxxxxxxxxxxx> Date: Sun, 09 Jun 2002 11:23:30 -0700 I need to account for packets on a per-session basis, where a session endpoint is a UDP port. So, knowing global proto
If the application only had 10 or fewer, non-critical UDP ports sending data, this conclusion might apply. However, even then, this suggestions seems a little silly. "Why don't you call for a full st
David S. Miller wrote: From: Ben Greear <greearb@xxxxxxxxxxxxxxx> Date: Sun, 09 Jun 2002 11:23:30 -0700 I need to account for packets on a per-session basis, where a session endpoint is a UDP port. S
At 09:34 PM 9/06/2002 -0700, David S. Miller wrote: Every argument I hear is one out of lazyness. And that is not a reason to add something. Simply put, I don't want to add all of this per-socket cou
What is the point? If all the dists will enable it then everybody eats the overhead. If the dists don't enable it, how useful is it and what's so wrong with it being an external patch people just app
I think i would agree with Dave for it to be an external patch. You really only need this during debugging. I had a similar patch when debugging NAPI about a year ago. I didnt find it that useful aft
In your case you found that you could solve it once by debugging the application. This doesn't mean that other applications would not be better at determining the code path to use at execution time.
I am confused as to which application needs this, do you have one in mind? AFAIK, UDP/RTP type apps already know how to determine packet loss on a per flow basis. You may be confusing technical merit
Author: Chris Friesen <cfriesen@xxxxxxxxxxxxxxxxxx>
Date: Mon, 10 Jun 2002 15:28:14 -0400
The purpose of this patch is to make it reallly easy to nail down exactly how many packets were dropped *per socket*, and for what reason. For me, the information is then used to tune the application