Re: [PATCH] USAGI IPsec

In article [off-list ref] (at Fri, 11 Oct 2002 18:53:32 -0700 (PDT)), "David S. Miller" [off-list ref] says:

We liked your implementation for it's simplicity.  But Alexey and
myself believe several details should be handled very much
differently.

Would you tell us the points of the "several details," please?

-- 
Hideaki YOSHIFUJI @ USAGI Project [off-list ref]
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

   From: YOSHIFUJI Hideaki / 吉藤英明 [off-list ref]
   Date: Sat, 12 Oct 2002 11:43:30 +0900 (JST)
   
   Would you tell us the points of the "several details," please?

We believe that the whole SPD/SAD mechanism should move
eventually to a top-level flow cache shared by ipv4 and
ipv6.

Therefore all the interfaces will be architected such that
a move to a flow cache based lookup system will be a very
simple change.

On Fri, Oct 11, 2002 at 07:41:08PM -0700, David S. Miller wrote:

   From: YOSHIFUJI Hideaki / ?$B5HF#1QL@ [off-list ref]
   Date: Sat, 12 Oct 2002 11:43:30 +0900 (JST)
   
   Would you tell us the points of the "several details," please?

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?

Regards,

bert hubert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

   From: bert hubert [off-list ref]
   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 :)

On Sat, 12 Oct 2002 04:41:37 -0700 (PDT)
"David S. Miller" [off-list ref] wrote:

   From: bert hubert [off-list ref]
   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

On Sat, Oct 12, 2002 at 04:41:37AM -0700, David S. Miller wrote:

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

Some people on #lartc were wondering about the use of a route cache if there
is only one route. It was reported that a single default route on a system
that talks to many destinations would lead to a huge route cache, which is
probably not more efficient than looking up the simple route.

Would this 'small efficient flow cache' also solve this problem?

Or is this problem a figment of people's imaginations?

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 :)

I know a lot of people are hoping that you make the feature freeze. As said
before, if there is any help you need, just yell.

Regards,

bert 

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

   From: Stephan von Krawczynski [off-list ref]
   Date: Sat, 12 Oct 2002 14:06:44 +0200

   This was a 2.2.19 kernel with equal-cost-multipath enabled
   and large routing-tables enabled.

It doesn't surprise me that 2.2.x performs like crap under
any real load btw :-)  It has none of the 2.3.x scalability
and threading work.

   From: bert hubert [off-list ref]
   Date: Sat, 12 Oct 2002 14:16:50 +0200

   Some people on #lartc were wondering about the use of a route cache if there
   is only one route. It was reported that a single default route on a system
   that talks to many destinations would lead to a huge route cache, which is
   probably not more efficient than looking up the simple route.
   
   Would this 'small efficient flow cache' also solve this problem?
   
I contend there is no "problem".  Routing cache entries are
garbage collected, and even this can be tuned via sysctl.