summaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authorH. Peter Anvin <hpa@linux.intel.com>2014-02-25 02:07:40 -0800
committerThomas Monjalon <thomas.monjalon@6wind.com>2014-02-25 11:52:35 +0100
commit65b0663b7f32e4157b71dc14a016215e1bc63157 (patch)
tree792215d2dc3af31dd2eb043d6e5dede33fdc0a77 /lib
parentea58c44bb78010cef3e7430725883660e0855b90 (diff)
downloaddpdk-65b0663b7f32e4157b71dc14a016215e1bc63157.zip
dpdk-65b0663b7f32e4157b71dc14a016215e1bc63157.tar.gz
dpdk-65b0663b7f32e4157b71dc14a016215e1bc63157.tar.xz
hash: reverse the operand order to crc32
Checkin a132a9cf2bcd440a974b9d3f5c44ba30b2c895a1 hash: use intrinsic changed the rte_hash_crc.h from using the crc32 instruction via inline assembly to using an intrinsic. The intrinsic should allow for better compiler performance, but the change did not account for the fact that the inline assembly being in AT&T syntax used the opposite operand order of the intrinsic. This turns out to not matter for correctness, because the CRC32 operation is commutative. However, it could potentially matter for performance, because the loop is more efficient with the moving pointer in the source operand and the accumulation in the destination operand. This was discovered by Jan Beulich when looking at the equivalent code in the Linux kernel. Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Reported-by: Jan Beulich <jbeulich@suse.com> Reported-by: Pashupati Kumar <kumarp@brocade.com> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Diffstat (limited to 'lib')
-rw-r--r--lib/librte_hash/rte_hash_crc.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index f10f139..1b9481e 100644
--- a/lib/librte_hash/rte_hash_crc.h
+++ b/lib/librte_hash/rte_hash_crc.h
@@ -60,7 +60,7 @@ extern "C" {
static inline uint32_t
rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
{
- return _mm_crc32_u32(data, init_val);
+ return _mm_crc32_u32(init_val, data);
}
/**