netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: nhorman@tuxdriver.com
Cc: netdev@vger.kernel.org, joe@nall.com,
	herbert@gondor.apana.org.au, kuznet@ms2.inr.ac.ru,
	pekkas@netcore.fi, jmorris@namei.org, yoshfuji@linux-ipv6.org,
	kaber@trash.net
Subject: Re: [PATCH] xfrm: export xfrm garbage collector thresholds via sysctl
Date: Mon, 27 Jul 2009 11:37:55 -0700 (PDT)	[thread overview]
Message-ID: <20090727.113755.260927092.davem@davemloft.net> (raw)
In-Reply-To: <20090727182246.GC15823@hmsreliant.think-freely.org>

From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 27 Jul 2009 14:22:46 -0400

> Export garbage collector thresholds for xfrm[4|6]_dst_ops
> 
> Had a problem reported to me recently in which a high volume of ipsec
> connections on a system began reporting ENOBUFS for new connections eventually.
> It seemed that after about 2000 connections we started being unable to create
> more.  A quick look revealed that the xfrm code used a dst_ops structure that
> limited the gc_thresh value to 1024, and alaways dropped route cache entries
> after 2x the gc_thresh.  It seems the most direct solution is to export the
> gc_thresh values in the xfrm[4|6] dst_ops as sysctls, like the main routing
> table does, so that higher volumes of connections can be supported.  This patch
> has been tested and allows the reporter to increase their ipsec connection
> volume successfully.
> 
> Reported-by: Joe Nall <joe@nall.com>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>

Applied, but this suggests that either:

1) we pick a horrible default

2) our IPSEC machinery holds onto dst entries too tightly and that's
   the true cause of this problem

I'd like to ask that you investigate this, because with defaults
we should be able to handle IPSEC loads as high as the routing
loads we could handle.

Thanks.

  reply	other threads:[~2009-07-27 18:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-27 18:22 [PATCH] xfrm: export xfrm garbage collector thresholds via sysctl Neil Horman
2009-07-27 18:37 ` David Miller [this message]
2009-07-27 19:36   ` Neil Horman
2009-07-27 19:40     ` David Miller
2009-07-27 20:02       ` Joe Nall
2009-07-27 20:10         ` David Miller

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=20090727.113755.260927092.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=jmorris@namei.org \
    --cc=joe@nall.com \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=pekkas@netcore.fi \
    --cc=yoshfuji@linux-ipv6.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;
as well as URLs for NNTP newsgroup(s).