>(does not jump). But remember that 2.2 is critical bug fixes only, a unnecessary
That's right to be done also in a 2.2.x stable trunk according to me.
>The basic idea behind header prediction is that you only turn it on if everything
>is normal. If anything unnormal happens you turn header prediction off (pred_flags = 0)
>and let it handle in the slow path. So for me it definitely does not look like the
Yes I've seen.
>right place for such a check.
The point is that checking only rmem is half of the work done from my
point of view. For a rcvbuf too small the fast-path is the normal-path.
>Other than that I think doing these costly hack just to cope with too small receive
>buffers is a bad idea. Just make sure the receive buffer is big enough
>
><tongue in cheek>
>if the user makes it too small it is his fault ("It hurts when I do that. Then don't do that.")
The user _can't_ predict which is the truesize of the bigger packet
involved in the transmission of data. Should he also take into account the
16bit alignment of truesize and the 16bit reserved by the hardware layer?
BTW why we are allocing in the skbuff data a atomic_t of space more?
>Also as Alexey noted a way to make the TCP stack drop all new incoming packets is sometimes
>useful.</>
Ok but for handle that you can instead simply use instead a special value
for rcvbuf (== 0) that will mean -> dropall incoming packets.
Andrea Arcangeli
-
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/