diff options
author | David S. Miller <davem@sunset.davemloft.net> | 2006-08-24 04:45:07 -0700 |
---|---|---|
committer | David S. Miller <davem@sunset.davemloft.net> | 2006-09-22 15:08:48 -0700 |
commit | 2518c7c2b3d7f0a6b302b4efe17c911f8dd4049f (patch) | |
tree | 7de05ca17d76eee141d4feff3b7b27d850557ae6 /net/xfrm/Makefile | |
parent | c1969f294e624d5b642fc8e6ab9468b7c7791fa8 (diff) | |
download | kernel_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