netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan von Krawczynski <skraw@ithnet.com>
To: "David S. Miller" <davem@redhat.com>
Cc: ahu@ds9a.nl, linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [PATCH] USAGI IPsec
Date: Sat, 12 Oct 2002 14:06:44 +0200	[thread overview]
Message-ID: <20021012140644.0d403b2c.skraw@ithnet.com> (raw)
In-Reply-To: <20021012.044137.42774593.davem@redhat.com>

On Sat, 12 Oct 2002 04:41:37 -0700 (PDT)
"David S. Miller" <davem@redhat.com> wrote:

>    From: bert hubert <ahu@ds9a.nl>
>    Date: Sat, 12 Oct 2002 13:17:59 +0200
> 
>    On Fri, Oct 11, 2002 at 07:41:08PM -0700, David S. Miller wrote:
>    > We believe that the whole SPD/SAD mechanism should move
>    > eventually to a top-level flow cache shared by ipv4 and
>    > ipv6.
>    
>    Is this the proposed stacked route system?
> 
> Yes, for output mostly.
> 
> Also the idea Alexey and I have to move towards a small
> efficient flow cache shared by IPv4/IPv6 plays into this
> as well.  There are changesets on their way to Linus tonight
> which moves ipv4 over to using ipv6's "struct flowi" from
> include/net/flow.h as the routing lookup key.
> 
> The initial ipsec is intended to be simple, singly linked
> lists for the spd/sad databases etc.  Making the feature
> freeze is pretty important right now, full blown flow cache
> is just performance improvement :)

Huhu!
Just a word on this one: I recently came across some heavy performance problem
regarding a setup with about 225 000 routes. It looked as if TCP experienced a
tremendous slowdown to about 50 KBytes/sec throughput, whereas UDP worked
pretty much normal. This was a 2.2.19 kernel with equal-cost-multipath enabled
and large routing-tables enabled.
The reason I am writing this is: please keep in mind situations like this with
several hundred thousands of routes in one box. This is a familiar setup for
the routing guys - and not a "just" case ;-)
Thanks for lending an ear.
-- 
Regards,
Stephan

  reply	other threads:[~2002-10-12 12:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m3u1js1l1a.wl@karaba.org>
     [not found] ` <20021011.185332.115906289.davem@redhat.com>
2002-10-12  2:43   ` [PATCH] USAGI IPsec YOSHIFUJI Hideaki / 吉藤英明
2002-10-12  2:41     ` David S. Miller
2002-10-12 11:17       ` bert hubert
2002-10-12 11:41         ` David S. Miller
2002-10-12 12:06           ` Stephan von Krawczynski [this message]
2002-10-13  5:42             ` David S. Miller
2002-10-12 12:16           ` bert hubert
2002-10-13  5:43             ` David S. Miller
2002-10-11  8:05 Mitsuru KANDA

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=20021012140644.0d403b2c.skraw@ithnet.com \
    --to=skraw@ithnet.com \
    --cc=ahu@ds9a.nl \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    /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).