Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
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
|
|
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
|
|
This patch introdcues basic types supporting fast path lookup.
Fast path performs policy matching with use of hash lookup
(particularly bihash tries has been used for that purpose). Fast path
lookup addresses situation where huge number of policies is created
(~100k or more). In such scenario adding/removing a policy
and policy matching is not efficient and poorly scales (for example
adding 500k policies takes a few hours. Also lookup time
increases significantly). With fast path adding and matching up to
1M flows scales up linearly (adding 1M of policies takes about 150s
on the test machine vs many hours in case of original implementation,
also matching time is significantly improved). Fast path will not
deal well with a huge number of policies that are spanning large
ip/port ranges. Large range will be masked out almost entirely leaving
only a few bits for calculating the hash key. Such keys will tend to
gather much more policies than other keys and hash will match most of
the packets anihilating advantages of hashing. Having said that
we also think that it is not the real life scenario.
Type: feature
Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com>
Change-Id: I600dae5111a37768ed4b23aa18426e66bbf7b529
|
|
Currently 0 has been used as the wildcard representing ANY type of
protocol. However 0 is valid value of ip protocol (HOPOPT) and therefore
it should not be used as a wildcard. Instead 255 is used which is
guaranteed by IANA to be reserved and not used as a protocol id.
Type: improvement
Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com>
Change-Id: I2320bae6fe380cb999dc5a9187beb68fda2d31eb
|
|
Type: fix
Fixes: 231c4696872cb344f28648949603840136c0795d
This reverts commit 231c4696872cb344f28648949603840136c0795d.
Change-Id: I136344555983dd10a31dbc000ee40e2de2c91291
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I4bfde738f9585b045cb5ba62cf51b141d639b1b2
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I5e981f12ff44243623cfd18d5e0ae06a7dfd1eb8
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- 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>
|
|
No function change. Only breaking the monster ipsec.[hc]
into smaller constituent parts
Change-Id: I3fd4d2d041673db5865d46a4002f6bd383f378af
Signed-off-by: Neale Ranns <nranns@cisco.com>
|