aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/ipsec/ipsec_spd_policy.c
AgeCommit message (Collapse)AuthorFilesLines
2023-03-20ipsec: set fast path 5tuple ip addresses based on sa traffic selector valuesPiotr Bronowski1-4/+35
Previously, even if sa defined traffic selectors esp packet src and dst have been used for fast path inbound spd matching. This patch provides a fix for that issue. Type: fix Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: Ibd3ca224b155cc9e0c6aedd0f36aff489b7af5b8
2022-11-28ipsec: remove redundant policy array in fast path spdPiotr Bronowski1-83/+42
Fast path spd was explicitely storing array of policy id vectors. This information was redundand, as this inofrmation is already stored in bihash table. This additional array was affecting performance when adding and removing fast path policies. The other place that needed refactoring after removing this array was cli command showing fast path policies. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I78d45653f71539e7ba90ff5d2834451f83ead4be
2022-11-21ipsec: improve ipsec policy adding performanceXiaoming Jiang1-19/+15
Type: improvement Signed-off-by: jiangxiaoming <jiangxiaoming@outlook.com> Change-Id: I91ba1ff4c1085f4aca60ca111cbbaf14a3b4d761
2022-09-21ipsec: introduce fast path ipv6 inbound matchingPiotr Bronowski1-33/+47
This patch introduces fast path matching for inbound traffic ipv6. Fast path uses bihash tables in order to find matching policy. Adding and removing policies in fast path is much faster than in current implementation. It is still new feature and further work needs and can be done in order to improve the perfromance. Type: feature Change-Id: Iaef6638033666ad6eb028ffe0c8a4f4374451753 Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com>
2022-09-12ipsec: introduce fast path ipv4 inbound matchingPiotr Bronowski1-87/+182
This patch introduces fast path matching for inbound traffic ipv4. Fast path uses bihash tables in order to find matching policy. Adding and removing policies in fast path is much faster than in current implementation. It is still new feature and further work needs and can be done in order to improve perfromance. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: Ifbd5bfecc21b76ddf8363f5dc089d77595196675
2022-08-02ipsec: fix coverity warnings found in fast path implementationPiotr Bronowski1-9/+10
This patch fixes followig coverity issues: CID 274739 Out-of-bounds read CID 274746 Out-of-bounds access CID 274748 Out-of-bounds read Type: fix Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I9bb6741f100a9414a5a15278ffa49b31ccd7994f
2022-07-15ipsec: fast path outbound policy matching implementation for ipv6Piotr Bronowski1-64/+92
With this patch fast path for ipv6 policy lookup is enabled. This impelentation scales and outperforms original implementation when the number of defined flows is higher thatn 100k. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I9364b5b8db4fc708790d48c538add272c7cea400
2022-06-29ipsec: add/delete ipsec fast path policyPiotr Bronowski1-57/+595
This patch introduces functions to add and delete fast path policies. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I3f1f1323148080c9dac531fbe9fa33bad4efe814
2022-04-14ipsec: perf improvement of ipsec4_input_node using flow cacheZachary Leaf1-1/+26
Adding flow cache support to improve inbound IPv4/IPSec Security Policy Database (SPD) lookup performance. By enabling the flow cache in startup conf, this replaces a linear O(N) SPD search, with an O(1) hash table search. This patch is the ipsec4_input_node counterpart to https://gerrit.fd.io/r/c/vpp/+/31694, and shares much of the same code, theory and mechanism of action. Details about the flow cache: Mechanism: 1. First packet of a flow will undergo linear search in SPD table. Once a policy match is found, a new entry will be added into the flow cache. From 2nd packet onwards, the policy lookup will happen in flow cache. 2. The flow cache is implemented using a hash table without collision handling. This will avoid the logic to age out or recycle the old flows in flow cache. Whenever a collision occurs, the old entry will be overwritten by the new entry. Worst case is when all the 256 packets in a batch result in collision, falling back to linear search. Average and best case will be O(1). 3. The size of flow cache is fixed and decided based on the number of flows to be supported. The default is set to 1 million flows, but is configurable by a startup.conf option. 4. Whenever a SPD rule is added/deleted by the control plane, all current flow cache entries will be invalidated. As the SPD API is not mp-safe, the data plane will wait for the control plane operation to complete. Cache invalidation is via an epoch counter that is incremented on policy add/del and stored with each entry in the flow cache. If the epoch counter in the flow cache does not match the current count, the entry is considered stale, and we fall back to linear search. The following configurable options are available through startup conf under the ipsec{} entry: 1. ipv4-inbound-spd-flow-cache on/off - enable SPD flow cache (default off) 2. ipv4-inbound-spd-hash-buckets %d - set number of hash buckets (default 4,194,304: ~1 million flows with 25% load factor) Performance with 1 core, 1 ESP Tunnel, null-decrypt then bypass, 94B (null encrypted packet) for different SPD policy matching indices: SPD Policy index : 2 10 100 1000 Throughput : Mbps/Mbps Mbps/Mbps Mbps/Mbps Mbps/Mbps (Baseline/Optimized) ARM TX2 : 300/290 230/290 70/290 8.5/290 Type: improvement Signed-off-by: Zachary Leaf <zachary.leaf@arm.com> Signed-off-by: mgovind <govindarajan.Mohandoss@arm.com> Tested-by: Jieqiang Wang <jieqiang.wang@arm.com> Change-Id: I8be2ad4715accbb335c38cd933904119db75827b
2022-02-18ipsec: fix vector after remove entry in spdGabriel Oginski1-1/+1
Originally after remove the policy entry in spd, macro "vec_del1" can change localization of the last entry in vector and finally the entry list has not been sorted. This patch fixes this issue by change executed macro "vec_delete" instead of "vec_del1". Type: fix Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com> Change-Id: I396591cbbe17646e1d243aedb4cdc272ed4d5e25
2021-10-12ipsec: Performance improvement of ipsec4_output_node using flow cacheGovindarajan Mohandoss1-0/+23
Adding flow cache support to improve outbound IPv4/IPSec SPD lookup performance. Details about flow cache: Mechanism: 1. First packet of a flow will undergo linear search in SPD table. Once a policy match is found, a new entry will be added into the flow cache. From 2nd packet onwards, the policy lookup will happen in flow cache. 2. The flow cache is implemented using bihash without collision handling. This will avoid the logic to age out or recycle the old flows in flow cache. Whenever a collision occurs, old entry will be overwritten by the new entry. Worst case is when all the 256 packets in a batch result in collision and fall back to linear search. Average and best case will be O(1). 3. The size of flow cache is fixed and decided based on the number of flows to be supported. The default is set to 1 million flows. This can be made as a configurable option as a next step. 4. Whenever a SPD rule is added/deleted by the control plane, the flow cache entries will be completely deleted (reset) in the control plane. The assumption here is that SPD rule add/del is not a frequent operation from control plane. Flow cache reset is done, by putting the data plane in fall back mode, to bypass flow cache and do linear search till the SPD rule add/delete operation is complete. Once the rule is successfully added/deleted, the data plane will be allowed to make use of the flow cache. The flow cache will be reset only after flushing out the inflight packets from all the worker cores using vlib_worker_wait_one_loop(). Details about bihash usage: 1. A new bihash template (16_8) is added to support IPv4 5 tuple. BIHASH_KVP_PER_PAGE and BIHASH_KVP_AT_BUCKET_LEVEL are set to 1 in the new template. It means only one KVP is supported per bucket. 2. Collision handling is avoided by calling BV (clib_bihash_add_or_overwrite_stale) function. Through the stale callback function pointer, the KVP entry will be overwritten during collision. 3. Flow cache reset is done using BV (clib_bihash_foreach_key_value_pair) function. Through the callback function pointer, the KVP value is reset to ~0ULL. MRR performance numbers with 1 core, 1 ESP Tunnel, null-encrypt, 64B for different SPD policy matching indices: SPD Policy index : 1 10 100 1000 Throughput : MPPS/MPPS MPPS/MPPS MPPS/MPPS KPPS/MPPS (Baseline/Optimized) ARM Neoverse N1 : 5.2/4.84 4.55/4.84 2.11/4.84 329.5/4.84 ARM TX2 : 2.81/2.6 2.51/2.6 1.27/2.6 176.62/2.6 INTEL SKX : 4.93/4.48 4.29/4.46 2.05/4.48 336.79/4.47 Next Steps: Following can be made as a configurable option through startup conf at IPSec level: 1. Enable/Disable Flow cache. 2. Bihash configuration like number of buckets and memory size. 3. Dual/Quad loop unroll can be applied around bihash to further improve the performance. 4. The same flow cache logic can be applied for IPv6 as well as in IPSec inbound direction. A deeper and wider flow cache using bihash_40_8 can replace existing bihash_16_8, to make it common for both IPv4 and IPv6 in both outbound and inbound directions. Following changes are made based on the review comments: 1. ON/OFF flow cache through startup conf. Default: OFF 2. Flow cache stale entry detection using epoch counter. 3. Avoid host order endianness conversion during flow cache lookup. 4. Move IPSec startup conf to a common file. 5. Added SPD flow cache unit test case 6. Replaced bihash with vectors to implement flow cache. 7. ipsec_add_del_policy API is not mpsafe. Cleaned up inflight packets check in control plane. Type: improvement Signed-off-by: mgovind <govindarajan.Mohandoss@arm.com> Signed-off-by: Zachary Leaf <zachary.leaf@arm.com> Tested-by: Jieqiang Wang <jieqiang.wang@arm.com> Change-Id: I62b4d6625fbc6caf292427a5d2046aa5672b2006
2020-04-24ipsec: add input node bypass/discard functionalityShivaShankarK1-0/+4
add bypass/discard functionality to ipsec4-input-feature node Type: feature Signed-off-by: ShivaShankarK <shivaashankar1204@gmail.com> Change-Id: I152a5dfee0296109cccabe349a330dbbe395cc6c
2019-07-12ipsec: Reference count the SAsNeale Ranns1-8/+12
- this remove the need to iterate through all state when deleting an SA - and ensures that if the SA is deleted by the client is remains for use in any state until that state is also removed. Type: feature Change-Id: I438cb67588cb65c701e49a7a9518f88641925419 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-06-13ipsec: remove spurious warningsNeale Ranns1-3/+0
Type: fix Fixes: 999c8ee6d6 Change-Id: Idcdddbe45f2e0adfd375b07199bb30f77c28702d Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-26IPSEC: improved policy deleteNeale Ranns1-13/+9
Change-Id: Icdf51b094c34725c079d2e4acbb955744434302d Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-19IPSEC: tidy the policy typesNeale Ranns1-68/+43
Change-Id: I5e981f12ff44243623cfd18d5e0ae06a7dfd1eb8 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-02-05IPSEC: SPD counters in the stats sgementNeale Ranns1-144/+116
- return the stats_index of each SPD in the create API call - no ip_any in the API as this creates 2 SPD entries. client must add both v4 and v6 explicitly - only one pool of SPD entries (rhter than one per-SPD) to support this - no packets/bytes in the dump API. Polling the stats segment is much more efficient (if the SA lifetime is based on packet/bytes) - emit the policy index in the packet trace and CLI commands. Change-Id: I7eaf52c9d0495fa24450facf55229941279b8569 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-02-01IPSEC: minor refactorNeale Ranns1-0/+266
No function change. Only breaking the monster ipsec.[hc] into smaller constituent parts Change-Id: I3fd4d2d041673db5865d46a4002f6bd383f378af Signed-off-by: Neale Ranns <nranns@cisco.com>