Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: passing skb ownership (was: ip_queue_xmit(): dangling skb pointer...) | Date | Wed, 15 Sep 1999 23:19:58 +0400 (MSK DST) |
| |
Hello!
> 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/
| |