> xmit queue which is limited by 4kB payload. Thus, with MTU 1500, the isdn
> internal queue length will not exceed 3-4 packets.
Yes, it is OK. Actually, the counting depends on link speed.
If it is enough high to hold rtt for MTU sized frame <= 200msec,
it is better not to violate this bound. If it is so low, that
this bound cannot be achieved in any case, it should be selected
so that queue_size/rate enough to make ssh/telnet more-or-less responsive.
> Given the analysis above, is it worthy to commit such (skb ovnership passing)
> changes or will it just complicate the driver code for very little gain?
Well, it is not so complicated. However, with small queue_size/rate
effect of such change is visible only if TCP window is set to small
value < queue_size (counting overhead).
> Another question: Is the optimal txqueuelen to be configured for the
> network interface somehow related to the length of the driver
> internal queue?
No. Actually, ideal variant is when driver holds the lowest possible
number of queued packets. It is 1 for slow drivers or higher number
for fast one. F.e. 2 is enough for 10Mbit ethernet, 16 is enough
for 100Mbit one.
> I think socket accounting will probably protect a user from filling up an
> unlimited queue by accident.
Alas, it will not.
for (;;) {
s = socket(AF_INET, SOCK_DGRAM, 0);
sendto(s, ...);
close(s);
}
will kill machine reliably and almost instantly, if driver queue
is unlimited.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/