[Top] [All Lists]

Re: [PATCH] Make xfrm subsystem optional

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: [PATCH] Make xfrm subsystem optional
From: Andi Kleen <ak@xxxxxxx>
Date: Sat, 14 Jun 2003 12:18:51 +0200
Cc: ak@xxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20030614.023843.78709528.davem@xxxxxxxxxx>
References: <20030614091631.GA16993@xxxxxxxxxxxxx> <20030614.022702.41637600.davem@xxxxxxxxxx> <20030614093630.GB16993@xxxxxxxxxxxxx> <20030614.023843.78709528.davem@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Sat, Jun 14, 2003 at 02:38:43AM -0700, David S. Miller wrote:
>    From: Andi Kleen <ak@xxxxxxx>
>    Date: Sat, 14 Jun 2003 11:36:30 +0200
>    Also when you do use it generically you will hopefully
>    discard some old code (like the rt cache?) which may make
>    up for the additional bloat. But until that happens having
>    both even when not needed doesn't make too much sense.
> The rtcache will likely be retained as a flow cache lookup
> miss handler even once we use the flowcache for all lookups.
> Actually, that entire area is in flux, I still do not know the
> fate of the rtcache even without the flow cache :)

In that case you could really apply the patch. It doesn't close
any future options for you, just makes live a bit better for 
some users today.

>    > How about working on making the xfrm layer more lean instead? :)
>    My last proposal for this (using hlists in the hash tables) was 
>    rejected, so I don't see much chance to do this.
> Because hlists cannot retain the behavior we need, specifically
> because we need the ability to add to the tail.
> If it's some in-kernel-image table, why not dynamically allocate the
> table in question?

Allocating it at first lookup would be racy (would need a nasty spinlock
at least). It may be possible at first policy setup, but it's not guaranteed 
can still get two 32K continuous areas. You could fall back to vmalloc I guess.

Allocating it at bootup would be equivalent to the current BSS allocation.

Advantage of the dynamic allocation is that it would work for vendor kernels


<Prev in Thread] Current Thread [Next in Thread>