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, CanadaOne ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/