> Hmmm... I don't see how not touching buffer values can solve his
> problem at all. His MTU is really HUGE, and in this case 300 byte
> packet eats 10k or so space in receive buffer.
Default rcvbuf is ~64K, it is enough to receive up to mtu of a bit less 64K.
When application says rcvbuf=2K it appearently does not expect to hold
more then one packet.
> I doubt our buffer size tuning algorithms can cope with this.
At least TCP will tune itself nicely under the most extremal conditions.
What's about this case, no chances to tune. rcvbuf just should be large.
> Really, copy threshold in driver just must be choosen carefully.
rx copybreak has no chances to work in the case of large mtus...
F.e. it does not with gigabit cards, which use 9K mtu, but need
to talk to 1.5K world. Blind copybreak at 1.5K is a non-sense,
meaning "copy all". Though acenic with its three rx rings is
a lucky exception. 8)
Alexey
-
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/