When create softnic hash table with 16 keys, it failed on 32-bit
environment, because the pointer field in structure rte_bucket_4_16
is only 32 bits. Add a padding field in 32-bit environment to keep
the structure to a multiple of 64 bytes. Apply this to 8-byte and
32-byte key hash function as well.
Fixes: 8aa327214c ("table: hash")
Cc: stable@dpdk.org
Signed-off-by: Ting Xu <ting.xu@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Replace the BSD license header with the SPDX tag for files
with only an Intel copyright on them.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Rework for the 8-byte key hash tables (both the extendible
bucket and LRU)to use the mask-based hash function and the
unified parameter structure.
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Add unified parameter structure for all hash tables in librte_table.
Add mask-based hash function prototype, which is input parameter for
all hash tables.
Renamed the non-mask-based hash function prototype and all the calls
to it (to be removed later).
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
The non-dosig version of the 8-byte key hash tables (both extendable
bucket and LRU) are removed. The remaining hash tables are renamed to
eliminate the dosig particle from their name.
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
In powerpc systems, rte table hash structs rte_bucket_4_8, rte_bucket_4_16 and
rte_bucket_4_32 are not cache aligned and hence verification on same would fail.
Instead of checking alignment on cpu cacheline, it could equally be tested as
multiple of 64 bytes.
Signed-off-by: Gowrishankar Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
This patch relates to ABI change proposed for librte_table.
The key_mask parameter is added for 8-byte and 16-byte
key extendible bucket and LRU tables.The release notes
is updated and the deprecation notice is removed.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
New functions prototypes for bulk add/delete added to table API. New
functions allows adding/deleting multiple records with single function
call. For now those functions are implemented only for ACL table. For
other tables these function pointers are set to NULL.
Signed-off-by: Maciej Gajdzica <maciejx.t.gajdzica@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Fix RTE_MBUF_METADATA macros to allow for unaligned accesses to
meta-data fields.
Forcing aligned accesses is not really required, so this is removing an
unneeded constraint.
This issue was met during testing of the new version of the ip_pipeline
application. There is no performance impact.
This change has no ABI impact, as the previous code that uses aligned
accesses continues to run without any issues.
Signed-off-by: Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
hash_key8_ext, hash_key16_ext and hash_key32_ext tables allocate cache
entries to support table overload cases. The crash can occur when cache
entry is free after use.
The problem is with computing the index of the free cache entry.
Signed-off-by: Mirek Walukiewicz <miroslaw.walukiewicz@intel.com>
Signed-off-by: Maciej Gajdzica <maciejx.t.gajdzica@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Include rte_memory.h for lib files that use __rte_cache_aligned
attribute.
Consider the following code:
struct per_core_foo {
...
} __rte_cache_aligned;
struct global_foo {
struct per_core_foo foo[RTE_MAX_CORE];
};
If __rte_cache_aligned is not defined (rte_memory.h is not included),
the code compiles but the structure is not aligned... it defines the
structure and creates a global variable called __rte_cache_aligned.
And this can lead to really bad things if this code is in a .h that
is included by files that may or may not include rte_memory.h
Signed-off-by: Jia Yu <jyu@vmware.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
CACHE_LINE_SIZE is a macro defined in machine/param.h in FreeBSD and
conflicts with DPDK macro version.
Adding RTE_ prefix to avoid conflicts.
CACHE_LINE_MASK and CACHE_LINE_ROUNDUP are also prefixed.
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
[Thomas: updated on HEAD, including PPC]
If a key is not found in a bucket and the bucket has been extended,
the extended buckets also have to checked for potentially matching
keys. The extended buckets are checked at the end of the lookup. In
most cases, this logic is skipped as it is uncommon to have buckets in
an extended state.
In case the lookup is performed with less than 5 packets, an
unoptimized version is run instead (the optimized version requires at
least 5 packets). The extended buckets should also be checked in this
case instead of simply ignoring the extended buckets.
Signed-off-by: Balazs Nemeth <balazs.nemeth@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Various types of hash tables presented under the Packet Framework toolbox.
Hash table types:
1. Extendible bucket (ext): when bucket is full, bucket is extended with
more keys
2. Least Recently Used (LRU): when bucket is full, the LRU entry is discarded
3. Pre-computed key signature: RX core extracts the key n-tuple from the
packet, computes the key signature and saves the key and key signature
within the packet meta-data; flow classification core performs the actual
lookup (the bucket search stage) after reading the key and key signature
from packet meta-data
4. Signature computed on-the-fly (do-sig version): the same CPU core extracts
the key n-tuple from pkt, computes key signature and performs the table
lookup
5. Configurable key size or optimized for single key size (8-byte, 16-byte
and 32-byte key sizes)
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Acked-by: Pablo de Lara Guarch <pablo.de.lara.guarch@intel.com>
Acked by: Ivan Boule <ivan.boule@6wind.com>
