And a default of 32 or 64K. You can tune those for your weird cases like
hippi via /proc. Thats covered already
> Its not exactly scientific evidence, I admit ;-) Maybe setting the max
> limit to 64KB for systems with less than 16MB and 256KB for systems
> with more memory?
If you are running big windows and your window scaling allows the full
buffer to be used you can make the buffers as big as you like and the problem
will not go away.
It is a queue problem, and as such changing the size of the queue just
makes the problem take a moment longer to occur.
The constraints required are pretty simple
1. Don't throw away in order queued data since it achieves nothing.
2. Don't offer a window that may cause an overcommit except in
statistically uninteresting cases
3. Don't queue partial frames in big buffers that would cause a violation
of rule #2
That basically means
o rx_copybreak >= 2/3 mtu
o memory >= 2 * buffer
so a default 64K buffer is fine (32K window - the largest offered without
scaling and well in excess of almost all users path lengths).
Alan
-
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/faq.html