aboutsummaryrefslogtreecommitdiffstats
path: root/net/xfrm/Makefile
diff options
context:
space:
mode:
authorDavid S. Miller <davem@sunset.davemloft.net>2006-08-24 04:45:07 -0700
committerDavid S. Miller <davem@sunset.davemloft.net>2006-09-22 15:08:48 -0700
commit2518c7c2b3d7f0a6b302b4efe17c911f8dd4049f (patch)
tree7de05ca17d76eee141d4feff3b7b27d850557ae6 /net/xfrm/Makefile
parentc1969f294e624d5b642fc8e6ab9468b7c7791fa8 (diff)
downloadkernel_samsung_smdk4412-2518c7c2b3d7f0a6b302b4efe17c911f8dd4049f.zip
kernel_samsung_smdk4412-2518c7c2b3d7f0a6b302b4efe17c911f8dd4049f.tar.gz
kernel_samsung_smdk4412-2518c7c2b3d7f0a6b302b4efe17c911f8dd4049f.tar.bz2
[XFRM]: Hash policies when non-prefixed.
This idea is from Alexey Kuznetsov. It is common for policies to be non-prefixed. And for that case we can optimize lookups, insert, etc. quite a bit. For each direction, we have a dynamically sized policy hash table for non-prefixed policies. We also have a hash table on policy->index. For prefixed policies, we have a list per-direction which we will consult on lookups when a non-prefix hashtable lookup fails. This still isn't as efficient as I would like it. There are four immediate problems: 1) Lots of excessive refcounting, which can be fixed just like xfrm_state was 2) We do 2 hash probes on insert, one to look for dups and one to allocate a unique policy->index. Althought I wonder how much this matters since xfrm_state inserts do up to 3 hash probes and that seems to perform fine. 3) xfrm_policy_insert() is very complex because of the priority ordering and entry replacement logic. 4) Lots of counter bumping, in addition to policy refcounts, in the form of xfrm_policy_count[]. This is merely used to let code path(s) know that some IPSEC rules exist. So this count is indexed per-direction, maybe that is overkill. Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/xfrm/Makefile')
0 files changed, 0 insertions, 0 deletions