Re: [net-next PATCH V2 1/9] net: frag evictor, avoid killing warm frag queues
From: Eric Dumazet <hidden>
Date: 2012-11-30 16:38:00
Subsystem:
networking [general], networking [ipv4/ipv6], the rest · Maintainers:
"David S. Miller", Eric Dumazet, Jakub Kicinski, Paolo Abeni, David Ahern, Ido Schimmel, Linus Torvalds
On Fri, 2012-11-30 at 16:45 +0100, Jesper Dangaard Brouer wrote:
On Fri, 2012-11-30 at 06:52 -0800, Eric Dumazet wrote:
quoted
I dont know how you expect that many datagrams being correctly reassembled with ipfrag_high_thresh=262144That's my point... I'm showing that its not possible, with out current implementation!
What I was saying is that the limits are too small, and we should increase them for this particular need. This has little to do with the underlying algo. Assuming we have a hash table size of 1024 buckets, you could easily add the following :
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 448e685..bc1bdf9 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c@@ -849,13 +849,13 @@ static inline void ip4_frags_ctl_register(void) static int __net_init ipv4_frags_init_net(struct net *net) { /* - * Fragment cache limits. We will commit 256K at one time. Should we - * cross that limit we will prune down to 192K. This should cope with + * Fragment cache limits. We will commit 4M at one time. Should we + * cross that limit we will prune down to 3M. This should cope with * even the most extreme cases without allowing an attacker to * measurably harm machine performance. */ - net->ipv4.frags.high_thresh = 256 * 1024; - net->ipv4.frags.low_thresh = 192 * 1024; + net->ipv4.frags.high_thresh = 4 << 20; + net->ipv4.frags.low_thresh = 3 << 20; /* * Important NOTE! Fragment queue must be destroyed before MSL expires. * RFC791 is wrong proposing to prolongate timer each fragment arrival