aboutsummaryrefslogtreecommitdiffstats
path: root/src/vppinfra/flowhash_template.h
AgeCommit message (Collapse)AuthorFilesLines
2020-04-22vppinfra: move unused code to extras/deprecated/vppinfraDave Barach1-608/+0
Type: improvement Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: Id28299a188feefa1899d835fd499f018af95d81b
2018-10-23c11 safe string handling supportDave Barach1-1/+1
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-08-20Enable storing state in flowhash hash tablesPierre Pfister1-1/+12
Flowhash user can now rely on the table to be initialized to zero and know when an entry is cleaned up by the garbage collector. This is usefull to store state in flowhash entries without the need for callbacks when an entry timeouts. Change-Id: Ieece6b7277241f84ea3f2473d0771c6ee8ce460c Signed-off-by: Pierre Pfister <ppfister@cisco.com>
2018-05-28Fix flowhash size computation for very large hash tablesPierre Pfister1-1/+1
Change-Id: Ieae4ff6429fc5bdcf0e243db40ab7ec00c30730a Signed-off-by: Pierre Pfister <ppfister@cisco.com>
2018-02-01Add flowhash hash table to vppinfraPierre Pfister1-0/+597
This hash table intends to provide an alternative to the widely used bihash table in places where either: - Hash entry timeout is required - The hash table data does not fit in CPU cache Although the bihash table is very fast, each lookup requires accessing two cache lines in a serialized fashion. It works fine when the hash table is in cache, but hits a wall when it does not. The 'flowhash' table uses a simplified design (at the cost of a less good bucket auto-scaling) where each access only requires a single memory lookup (in the absence of collision). The hash table also uses a reduced number of registers. In practice, a VPP node implementing a stateful feature would typically: - prefetch buffer metadata (in-cache) - prefetch packet header (in-cache) - compute hash & prefetch hash bucket (possibly in RAM) - read/write key and value from bucket Using this hash table, it is possible to pipeline accesses in a way that does not exhaust CPU's line field buffers, even when the requested value is located in RAM (i.e. not in cache). Measurements showed it was possible to scale to tens of millions of flows (with a full 5-tuple matching and 32B value, i.e. 1 cache line per flow) with no performance degradation when the hash table grows to the point it doesn't fit in cache anymore. I have used this table in a couple of non-open-sourced projects, but think it might be useful to lb, nat, and possibly other VPP subsystems. More information in the .h file. Change-Id: I2b13dde0eabd868b75da1cedbfca0bf74d705102 Signed-off-by: Pierre Pfister <ppfister@cisco.com>