netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Josefsson <gandalf@wlug.westbo.se>
To: Andi Kleen <ak@suse.de>
Cc: jamal <hadi@cyberus.ca>, Rusty Russell <rusty@rustcorp.com.au>,
	Netfilter-devel <netfilter-devel@lists.netfilter.org>,
	netdev@oss.sgi.com, netfilter-core@lists.netfilter.org,
	Patrick Schaaf <bof@bof.de>
Subject: Re: TODO list before feature freeze
Date: 29 Jul 2002 17:40:18 +0200	[thread overview]
Message-ID: <1027957218.12610.71.camel@tux> (raw)
In-Reply-To: <20020729135615.A20412@wotan.suse.de>

On Mon, 2002-07-29 at 13:56, Andi Kleen wrote:

> here is a patch for 2.4 that just makes it use get_free_pages to test the 
> TLB theory. Another obvious improvement would be to not use list_heads 
> for the hash table buckets - a single pointer would likely suffice and 
> it would cut the hash table in half, saving cache, TLB and memory.

I think the list_heads are used for only one thing currently, for the
early eviction in case of overload, then it scans backwards in the
chains to find unreplied connections to evict, or so the comment in
early_drop() says:

/* Traverse backwards: gives us oldest, which is roughly LRU */

but then it uses the normal LIST_FIND macro which I think traverses the
list in the normal forward direction. I havn't looked into the rest of
the code but I can't seem to remember anything that needs list_heads.

I think Patrick Schaaf is looking into conntrack as we speak. Maybe he
has any ideas?

I know I've had plans on rewriting the locking in conntrack which is
quite frankly horrible, one giant rwlock used for almost everything
(including the hashtable). One idea that has come to mind is using RCU
(need to learn more about it) or maybe use one rwlock per N buckets or
something. Looking at some stats from one of my routers I see that an
average connection is over 130 packets long so the ratio between reads
and writes is quite good.

And this eviction which occurs at overload needs to be redone, we can't
go around dropping one unreplied connection at a time, we need
gang-eviction of unreplied connections. We've had some nasty DDoS's here
in which our routers have been spending all cputime in conntrack trying
to evict connections to make room for the SYN floods coming in at
>130kpps.

-- 
/Martin

Never argue with an idiot. They drag you down to their level, then beat
you with experience.

  reply	other threads:[~2002-07-29 15:40 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-18  9:34 TODO list before feature freeze Rusty Russell
2002-07-19  7:39 ` Balazs Scheidler
2002-07-19 17:43 ` Michael Richardson
2002-07-29 10:57 ` jamal
2002-07-29 11:12   ` Andi Kleen
2002-07-29 11:23     ` jamal
2002-07-29 11:56       ` Andi Kleen
2002-07-29 15:40         ` Martin Josefsson [this message]
2002-07-29 16:15           ` Patrick Schaaf
2002-07-29 17:12             ` Martin Josefsson
2002-07-29 17:35               ` Nivedita Singhvi
2002-07-29 22:43         ` Martin Josefsson
2002-07-29 16:26       ` Patrick Schaaf
2002-07-29 16:31         ` Andi Kleen
2002-07-29 16:42           ` Patrick Schaaf
2002-07-29 16:45             ` Patrick Schaaf
2002-07-30 11:58         ` jamal
2002-07-30 12:27           ` Patrick Schaaf
2002-07-30 12:29             ` jamal
2002-07-30 13:06               ` Patrick Schaaf
2002-07-30 13:42                 ` jamal
2002-07-30 13:08               ` Martin Josefsson
2002-07-30 15:54                 ` Filip Sneppe (Cronos)
2002-07-29 15:25     ` Michael Richardson
2002-07-29 15:52       ` Patrick Schaaf
2002-07-29 20:51       ` Andi Kleen
2002-07-30  7:26         ` Patrick Schaaf
2002-07-29 22:14   ` Rusty Russell
2002-07-30 12:04     ` jamal

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=1027957218.12610.71.camel@tux \
    --to=gandalf@wlug.westbo.se \
    --cc=ak@suse.de \
    --cc=bof@bof.de \
    --cc=hadi@cyberus.ca \
    --cc=netdev@oss.sgi.com \
    --cc=netfilter-core@lists.netfilter.org \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=rusty@rustcorp.com.au \
    /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;
as well as URLs for NNTP newsgroup(s).