From: Eric Dumazet <eric.dumazet@gmail.com>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC PATCH] inet: fix enforcing of fragment queue hash list depth
Date: Mon, 15 Apr 2013 09:23:50 -0700 [thread overview]
Message-ID: <1366043030.4459.109.camel@edumazet-glaptop> (raw)
In-Reply-To: <20130415152637.GA29378@order.stressinduktion.org>
On Mon, 2013-04-15 at 17:26 +0200, Hannes Frederic Sowa wrote:
> Hi Jesper!
>
> On Mon, Apr 15, 2013 at 04:25:10PM +0200, Jesper Dangaard Brouer wrote:
> > I have found an issues with commit:
> >
> > commit 5a3da1fe9561828d0ca7eca664b16ec2b9bf0055
> > Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Date: Fri Mar 15 11:32:30 2013 +0000
> >
> > inet: limit length of fragment queue hash table bucket lists
> >
> > There is a connection between the fixed 128 hash depth limit and the
> > frag mem limit/thresh settings, which limits how high the thresh can
> > be set.
> >
> > The 128 elems hash depth limit, results in bad behaviour if mem limit
> > thresh holds are increased, via /proc/sys/net ::
> >
> > /proc/sys/net/ipv4/ipfrag_high_thresh
> > /proc/sys/net/ipv4/ipfrag_low_thresh
> >
> > If we increase the thresh, to something allowing 128 elements in each
> > bucket, which is not that high given the hash array size of 64
> > (64*128=8192), e.g.
> > big MTU frags (2944(truesize)+208(ipq))*8192(max elems)=25755648
> > small frags ( 896(truesize)+208(ipq))*8192(max elems)=9043968
>
> I thought it was pretty high already. While creating this patch I also
> had a patch which did calculate the chain limit while updating the sysctl
> high_thresh knob (perhaps this could be of use):
>
> http://patchwork.ozlabs.org/patch/227136/
>
> Perhaps we should reconsider the formula I choose to calculate this limit.
> But because we would actually have 128 iterations in the hash bucket I
> am more in favor of resizing (or even come up with a way to dynamically
> resize) the hash table. On a smaller sized machine I can actually create
> severe latency because of the list iteration even with the 128 list length
> limit in place.
Allowing thousand of fragments and keeping a 64 slot hash table is not
going to work.
depths of 128 are just insane.
Really Jesper, you'll need to make the hash table dynamic, if you really
care.
next prev parent reply other threads:[~2013-04-15 16:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-15 14:25 [RFC PATCH] inet: fix enforcing of fragment queue hash list depth Jesper Dangaard Brouer
2013-04-15 15:26 ` Hannes Frederic Sowa
2013-04-15 16:23 ` Eric Dumazet [this message]
2013-04-15 17:09 ` Hannes Frederic Sowa
2013-04-15 17:12 ` Jesper Dangaard Brouer
2013-04-15 17:16 ` Jesper Dangaard Brouer
2013-04-15 17:43 ` Hannes Frederic Sowa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1366043030.4459.109.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox