From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp0.epfl.ch (smtp0.epfl.ch [128.178.224.218]) by dpdk.org (Postfix) with ESMTP id 8FD4B106A for ; Sat, 21 Jan 2017 23:16:10 +0100 (CET) Received: (qmail 28729 invoked by uid 107); 21 Jan 2017 22:16:08 -0000 X-Virus-Scanned: ClamAV Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) (TLS, DHE-RSA-AES256-SHA cipher) (authenticated) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPSA; Sat, 21 Jan 2017 23:16:08 +0100 Received: by mail-wm0-f46.google.com with SMTP id r144so97650003wme.1 for ; Sat, 21 Jan 2017 14:16:07 -0800 (PST) X-Gm-Message-State: AIkVDXIDpHD45JNO7Q2nPSGdYUYAqL8Ow5U5i5k9ecUaPAX3MSHEkzjCTbAZea+1gvnpMDOniqCUH2DYGtRAcA== X-Received: by 10.28.17.133 with SMTP id 127mr7843794wmr.80.1485036966596; Sat, 21 Jan 2017 14:16:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.49.136 with HTTP; Sat, 21 Jan 2017 14:15:46 -0800 (PST) From: Solal Pirelli Date: Sat, 21 Jan 2017 23:15:46 +0100 X-Gmail-Original-Message-ID: Message-ID: To: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] Bug report: rte_table_hash_ext incorrectly compares signatures X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 22:16:10 -0000 Hi, I found a bug in the rte_table_hash_ext implementation, hopefully this mailing list is the right place to report it. It's pretty simple: in `rte_table_hash_ext.c` (using `add` as an example; the bug is also elsewhere): - line 53 declares the bucket signatures as arrays of `uint16_t` - line 280 computes the key signature, an `uint64_t` - line 283 shifts the signature by 16 bits to the right, resulting in a "48-bit" number - like 293 then compares the bucket signature (16 bits) to the shifted key signature (48 bits). Thus, rte_table_hash_ext only works if hashes have their upper 32 bits unset. I created a tiny repro: https://github.com/SolalPirelli/dpdk-table-hash-ext-bug It tries to insert then retrieve the same key/value pair, with specific bits set in the hash; as can be seen from the output, the map works fine when only one of the lower 32 bits is set, but stops working if one of the upper 32 bits is. The workaround is simple: the hash function should always clear the upper 32 bits of its output. (I unfortunately don't have the time right now to provide a properly-tested patch, sorry) Cheers, Solal Pirelli