lkml.org 
[lkml]   [2001]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: skb->truesize > sk->rcvbuf == Dropped packets
Date
Hello!

> 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/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.035 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site