All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>,
	netdev@vger.kernel.org
Subject: Re: [net-next PATCH 2/3] net: fix enforcing of fragment queue hash list depth
Date: Wed, 24 Apr 2013 15:35:23 +0200	[thread overview]
Message-ID: <1366810523.26911.495.camel@localhost> (raw)
In-Reply-To: <1366382991.16391.6.camel@edumazet-glaptop>

On Fri, 2013-04-19 at 07:49 -0700, Eric Dumazet wrote:
> On Fri, 2013-04-19 at 14:19 +0200, Jesper Dangaard Brouer wrote:
> 
> > When removing the LRU system (which is the real bottleneck, see perf
> > tests in cover mail), and doing direct hash cleaning we are trading-in
> > accuracy.
[...]
> > The reason I don't want a too big hash table is the following.
> > 
> > Worst case 1024 buckets * 130K bytes = 133 MBytes, which on smaller
> > embedded systems is a lot of kernel memory we are permitting a remote
> > host to "lock-down".
> 
> Thats pretty irrelevant, memory is limited by the total amount of memory
> used by fragments, not by hash table size.
>
> Its called /proc/sys/net/ipv4/ipfrag_high_thresh


I was talking about patch-03, where I do "direct hash cleaning", and
have moved the mem limit "ipfrag_high_thresh" into the hash cleaning
step.

It seems we are talking past each-other...

--Jesper

  reply	other threads:[~2013-04-24 13:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-18 21:37 [net-next PATCH 0/3] net: frag code fixes and RFC for LRU removal Jesper Dangaard Brouer
2013-04-18 21:37 ` [net-next PATCH 1/3] net: fix race bug in fragmentation create code Jesper Dangaard Brouer
2013-04-19  1:00   ` Hannes Frederic Sowa
2013-04-19  8:09     ` Jesper Dangaard Brouer
2013-04-18 21:38 ` [net-next PATCH 2/3] net: fix enforcing of fragment queue hash list depth Jesper Dangaard Brouer
2013-04-19  0:52   ` Hannes Frederic Sowa
2013-04-19 10:11   ` Eric Dumazet
2013-04-19 10:41     ` David Laight
2013-04-19 11:14       ` Eric Dumazet
2013-04-19 12:19     ` Jesper Dangaard Brouer
2013-04-19 12:45       ` Hannes Frederic Sowa
2013-04-19 14:29         ` Jesper Dangaard Brouer
2013-04-19 15:06           ` Hannes Frederic Sowa
2013-04-19 19:44           ` Hannes Frederic Sowa
2013-04-22  9:10             ` Jesper Dangaard Brouer
2013-04-22 14:54               ` Hannes Frederic Sowa
2013-04-22 16:30                 ` Jesper Dangaard Brouer
2013-04-22 17:49                 ` Jesper Dangaard Brouer
2013-04-23  0:20                   ` Hannes Frederic Sowa
2013-04-23 14:19                     ` Jesper Dangaard Brouer
2013-04-23 20:54                       ` Hannes Frederic Sowa
2013-04-19 14:42       ` Eric Dumazet
2013-04-19 14:45       ` Eric Dumazet
2013-04-19 14:45       ` Eric Dumazet
2013-04-19 14:49       ` Eric Dumazet
2013-04-24 13:35         ` Jesper Dangaard Brouer [this message]
2013-04-24 15:05           ` Eric Dumazet
2013-04-18 21:39 ` [RFC net-next PATCH 3/3] net: remove fragmentation LRU list system Jesper Dangaard Brouer

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=1366810523.26911.495.camel@localhost \
    --to=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.