From: Mark Mielke <hidden> Date: 2002-06-10 14:04:26
On Mon, Jun 10, 2002 at 08:24:44AM -0400, jamal wrote:
On Mon, 10 Jun 2002, David S. Miller wrote:
quoted
From: Lincoln Dale [off-list ref]
Date: Mon, 10 Jun 2002 22:03:25 +1000
would you be willing to accept a patch that enables per-socket
accounting with a CONFIG_ option?
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 apply when they need to
diagnose something like this?
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 after
a while because i could deduce the losses from SNMP/netstat output.
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.
Just because eth1 is behaving perfectly (i.e. low overall dropped UDP
packets, or low TCP/IP retransmission) does not mean that a specific
socket currently on eth1 heading to China should assume that it can
take the 'average' observation as adequate for observing the specific
socket.
There *are* applications that would benefit from making this decision
at run time on a socket-by-socket basis. It is not a common requirement
for most desktop users, but it remains a valid requirement.
Providing it as a patch, can have the effect that it becomes more trouble
than it is worth to grant other people access to the feature, especially
from a corporate environment that has signed off on being able to release
patches made to Linux back to the Linux source tree.
Seems somewhat of a loss...
mark
--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
On Mon, Jun 10, 2002 at 08:24:44AM -0400, jamal wrote:
quoted
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 after
a while because i could deduce the losses from SNMP/netstat output.
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.
Just because eth1 is behaving perfectly (i.e. low overall dropped UDP
packets, or low TCP/IP retransmission) does not mean that a specific
socket currently on eth1 heading to China should assume that it can
take the 'average' observation as adequate for observing the specific
socket.
There *are* applications that would benefit from making this decision
at run time on a socket-by-socket basis. It is not a common requirement
for most desktop users, but it remains a valid requirement.
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.
Providing it as a patch, can have the effect that it becomes more trouble
than it is worth to grant other people access to the feature, especially
from a corporate environment that has signed off on being able to release
patches made to Linux back to the Linux source tree.
You may be confusing technical merit to mean the same thing as corporate
donation. In Linux its the later that counts.
Seems somewhat of a loss...
Your mileage may vary. Consider this - you have the opp to at least
make the patch available. Imagine trying to convince windriver.
cheers,
jamal
mark
--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
From: Chris Friesen <hidden> Date: 2002-06-10 19:28:14
jamal wrote:
On Mon, 10 Jun 2002, Mark Mielke wrote:
quoted
There *are* applications that would benefit from making this decision
at run time on a socket-by-socket basis. It is not a common requirement
for most desktop users, but it remains a valid requirement.
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.
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 statically, but others could
use it dynamically. Incoming packets can be dropped at the device, at the
device driver, in netif_rx, or at the socket buffer. We've got stats on all of
these except for the socket buffer, so why not add them?
The cost in the normal case is incrementing a single variable in the socket
struct (which is likely already in cache since we're playing with it). I can't
see this being that expensive. In the failure path, we get a second increment.
Again, this is not going to be noticeable.
Sure, you can try and figure out which applications had sockets open, and how
many packets they missed, and subtract that from the snmp counters to give how
many packets you missed. But to do this you have to lock the box down--isn't it
a lot easier to just *know* because you've been keeping track?
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
From: Chris Friesen <hidden> Date: 2002-06-10 19:28:14
jamal wrote:
On Mon, 10 Jun 2002, Mark Mielke wrote:
quoted
There *are* applications that would benefit from making this decision
at run time on a socket-by-socket basis. It is not a common requirement
for most desktop users, but it remains a valid requirement.
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.
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 statically, but others could
use it dynamically. Incoming packets can be dropped at the device, at the
device driver, in netif_rx, or at the socket buffer. We've got stats on all of
these except for the socket buffer, so why not add them?
The cost in the normal case is incrementing a single variable in the socket
struct (which is likely already in cache since we're playing with it). I can't
see this being that expensive. In the failure path, we get a second increment.
Again, this is not going to be noticeable.
Sure, you can try and figure out which applications had sockets open, and how
many packets they missed, and subtract that from the snmp counters to give how
many packets you missed. But to do this you have to lock the box down--isn't it
a lot easier to just *know* because you've been keeping track?
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
From: Chris Friesen <hidden> Date: 2002-06-10 19:28:14
jamal wrote:
On Mon, 10 Jun 2002, Mark Mielke wrote:
quoted
There *are* applications that would benefit from making this decision
at run time on a socket-by-socket basis. It is not a common requirement
for most desktop users, but it remains a valid requirement.
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.
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 statically, but others could
use it dynamically. Incoming packets can be dropped at the device, at the
device driver, in netif_rx, or at the socket buffer. We've got stats on all of
these except for the socket buffer, so why not add them?
The cost in the normal case is incrementing a single variable in the socket
struct (which is likely already in cache since we're playing with it). I can't
see this being that expensive. In the failure path, we get a second increment.
Again, this is not going to be noticeable.
Sure, you can try and figure out which applications had sockets open, and how
many packets they missed, and subtract that from the snmp counters to give how
many packets you missed. But to do this you have to lock the box down--isn't it
a lot easier to just *know* because you've been keeping track?
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
From: Chris Friesen <hidden> Date: 2002-06-10 19:28:14
jamal wrote:
On Mon, 10 Jun 2002, Mark Mielke wrote:
quoted
There *are* applications that would benefit from making this decision
at run time on a socket-by-socket basis. It is not a common requirement
for most desktop users, but it remains a valid requirement.
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.
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 statically, but others could
use it dynamically. Incoming packets can be dropped at the device, at the
device driver, in netif_rx, or at the socket buffer. We've got stats on all of
these except for the socket buffer, so why not add them?
The cost in the normal case is incrementing a single variable in the socket
struct (which is likely already in cache since we're playing with it). I can't
see this being that expensive. In the failure path, we get a second increment.
Again, this is not going to be noticeable.
Sure, you can try and figure out which applications had sockets open, and how
many packets they missed, and subtract that from the snmp counters to give how
many packets you missed. But to do this you have to lock the box down--isn't it
a lot easier to just *know* because you've been keeping track?
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
From: Chris Friesen <hidden> Date: 2002-06-10 19:28:30
jamal wrote:
On Mon, 10 Jun 2002, Mark Mielke wrote:
quoted
There *are* applications that would benefit from making this decision
at run time on a socket-by-socket basis. It is not a common requirement
for most desktop users, but it remains a valid requirement.
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.
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 statically, but others could
use it dynamically. Incoming packets can be dropped at the device, at the
device driver, in netif_rx, or at the socket buffer. We've got stats on all of
these except for the socket buffer, so why not add them?
The cost in the normal case is incrementing a single variable in the socket
struct (which is likely already in cache since we're playing with it). I can't
see this being that expensive. In the failure path, we get a second increment.
Again, this is not going to be noticeable.
Sure, you can try and figure out which applications had sockets open, and how
many packets they missed, and subtract that from the snmp counters to give how
many packets you missed. But to do this you have to lock the box down--isn't it
a lot easier to just *know* because you've been keeping track?
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