From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2972041CA5; Wed, 15 Feb 2023 12:39:27 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0CFB0410DD; Wed, 15 Feb 2023 12:39:27 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 8BDE740EE3 for ; Wed, 15 Feb 2023 12:39:26 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v3] hash: add XOR32 hash function Date: Wed, 15 Feb 2023 12:39:22 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87740@smartserver.smartshare.dk> In-Reply-To: <20230215110630.3885175-1-qobilidop@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v3] hash: add XOR32 hash function Thread-Index: AdlBLZw73QdPMHxqR0SfP4CC6lxoeAAAhpYQ References: <20230215105442.3878441-1-qobilidop@gmail.com> <20230215110630.3885175-1-qobilidop@gmail.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bili Dong" , Cc: , X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Bili Dong [mailto:qobilidop@gmail.com] > Sent: Wednesday, 15 February 2023 12.07 >=20 > An XOR32 hash is needed in the Software Switch (SWX) Pipeline for its > use case in P4. We implement it in this patch so it could be easily > registered in the pipeline later. >=20 > Signed-off-by: Bili Dong > --- [...] > +#define LEFT8b_MASK rte_cpu_to_be_32(0xff000000) > +#define LEFT16b_MASK rte_cpu_to_be_32(0xffff0000) > + > +/** > + * Calculate XOR32 hash on user-supplied byte array. > + * > + * @param data > + * Data to perform hash on. > + * @param data_len > + * How many bytes to use to calculate hash value. > + * @param init_val > + * Value to initialise hash generator. > + * @return > + * 32bit calculated hash value. > + */ > +static inline uint32_t > +rte_hash_xor(const void *data, uint32_t data_len, uint32_t init_val) > +{ > + uint32_t i; > + uintptr_t pd =3D (uintptr_t) data; > + init_val =3D rte_cpu_to_be_32(init_val); > + > + for (i =3D 0; i < data_len / 4; i++) { > + init_val ^=3D *(const uint32_t *)pd; > + pd +=3D 4; > + } > + > + if (data_len & 0x2) { > + init_val ^=3D *(const uint32_t *)pd & LEFT16b_MASK; > + pd +=3D 2; > + } > + > + if (data_len & 0x1) > + init_val ^=3D *(const uint32_t *)pd & LEFT8b_MASK; > + > + init_val =3D rte_be_to_cpu_32(init_val); > + return init_val; > +} I think that this function has swapped big endian and CPU endian = everywhere. The result is the same, but the code would be much less = confusing if using rte_cpu_32_to_be() when converting from CPU endian to = big endian, and rte_be_to_cpu_32() when converting the other way. I also suppose that the return type and the init_val parameter were = meant to be rte_be32_t. Also, please document that the byte array must be 32 bit aligned. = Alternatively, implement support for unaligned data. You can find = inspiration for handling of unaligned data in the __rte_raw_cksum() = function: https://elixir.bootlin.com/dpdk/v22.11.1/source/lib/net/rte_ip.h#L162