From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id A1C5341CF0;
Mon, 20 Feb 2023 21:18:02 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 95A27430EB;
Mon, 20 Feb 2023 21:18:02 +0100 (CET)
Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com
[209.85.208.52]) by mails.dpdk.org (Postfix) with ESMTP id 60CF2430E3
for <dev@dpdk.org>; Mon, 20 Feb 2023 21:18:01 +0100 (CET)
Received: by mail-ed1-f52.google.com with SMTP id g1so8765954edz.7
for <dev@dpdk.org>; Mon, 20 Feb 2023 12:18:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=go8esWZ1creEiVl1GJAYU9QTTAcDBztIAJpXzOcBdno=;
b=U5Pt1+iTRWnv87tFV8YxNfYYkfSOcvF8SeqL/+EfaaQ0+sFy9I1y0B79x72iFrtLw0
eVLt+02KdiFowttAYzaGXOaQeIaZH6R9TfpCXN+VLCNaWk5cejPbeqfWHW/5bMsDe8ad
podUvngjNpDSL08pHKyhJM9mkBhxLwNs6c4H6cYR1hyNsvAPXOp2ZlNgXcCAUjvtpyMA
tEYmPSNBJ/PbRjot+IErNasiURja6dzOZLsap285kQ6FDzrpH1ILf5N0jQ/3iDjbRIHf
srhlwgWz2RcO2J4r3D0a39Ka0QpGB3JdvTYEvQhMscyrjuZQr9gEOYlh3KtDADurBbp0
TrhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=go8esWZ1creEiVl1GJAYU9QTTAcDBztIAJpXzOcBdno=;
b=btkCSFnqtox55092O7+SR1n+xT/EeUg+aws0KXUSiOMvWJ8sONARPpuPelnvyz1YH/
cwAmU74/Q+55eAzQPxC/ruwW3vVPcjSc6RhlE+WVdZjZuLkSUAHsmtwAtewkgozOx7hB
AJM3TdFMzh10avOkKXO4GPy28K8jB0FqXitihPabYAWBfy4EgMgnkL74fSfjgu5ZEMLi
tmQgLVU6yAPJmekJoKLpcLFQgxnL6rItmbWMSTpOIyojcLyLp+F/yjm677JYJEZ+nzud
wJX2/vW+7/BPUmBYOKBAWtadKn5ugLbO95j6fbIB7Q51KDaNt/L2HyjSZ4IYIdJAwD+w
YQcA==
X-Gm-Message-State: AO0yUKVcXk4CuxYLJzwhpcomsMJsnwkmVgDA+D2f4Yw3XskxyFRkOeQm
3RstJlBnbmeMtFBGlsOCB2hmQqw88/SLIu7fesI=
X-Google-Smtp-Source: AK7set9Wu0uMlkeCZuMkNHKwa+MDv2fQgIyFsX5wcSkG1/dPy2AhgtDfANgxQCtAwKotsdQ/JaOQPs/TIr/xro4FGgk=
X-Received: by 2002:a17:906:c20e:b0:8cc:757e:423c with SMTP id
d14-20020a170906c20e00b008cc757e423cmr2403317ejz.7.1676924280909; Mon, 20 Feb
2023 12:18:00 -0800 (PST)
MIME-Version: 1.0
References: <20230215105442.3878441-1-qobilidop@gmail.com>
<20230215110630.3885175-1-qobilidop@gmail.com>
<18974072-6d67-c82b-bd69-3eb54f631573@intel.com>
In-Reply-To: <18974072-6d67-c82b-bd69-3eb54f631573@intel.com>
From: Bili Dong <qobilidop@gmail.com>
Date: Mon, 20 Feb 2023 12:17:24 -0800
Message-ID: <CAFnY8dHb6jhzAMC+FYHq_8b3J=p3q0rF219a_e=n7NXUnJkoqA@mail.gmail.com>
Subject: Re: [PATCH v3] hash: add XOR32 hash function
To: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>
Cc: yipeng1.wang@intel.com, dev@dpdk.org, cristian.dumitrescu@intel.com
Content-Type: multipart/alternative; boundary="0000000000001435bb05f5275cc5"
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
--0000000000001435bb05f5275cc5
Content-Type: text/plain; charset="UTF-8"
Got it. Will fix. Thanks!
On Mon, Feb 20, 2023 at 12:10 PM Medvedkin, Vladimir <
vladimir.medvedkin@intel.com> wrote:
> Hi Bill,
>
> On 15/02/2023 11:06, Bili Dong wrote:
> > 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.
> >
> > Signed-off-by: Bili Dong <qobilidop@gmail.com>
> > ---
> > +static inline uint32_t
> > +rte_hash_xor(const void *data, uint32_t data_len, uint32_t init_val)
> > +{
> > + uint32_t i;
> > + uintptr_t pd = (uintptr_t) data;
> > + init_val = rte_cpu_to_be_32(init_val);
> > +
> > + for (i = 0; i < data_len / 4; i++) {
> > + init_val ^= *(const uint32_t *)pd;
> > + pd += 4;
> > + }
> > +
> > + if (data_len & 0x2) {
> > + init_val ^= *(const uint32_t *)pd & LEFT16b_MASK;
>
> Here you are reading 2 bytes after the data buffer, which can sometimes
> lead to segfault. I think it would be better just to:
>
> init_val ^= *(const uint16_t *)pd << 16;
>
> The same with the section bellow
>
> > + pd += 2;
> > + }
> > +
> > + if (data_len & 0x1)
> > + init_val ^= *(const uint32_t *)pd & LEFT8b_MASK;
> > +
> > + init_val = rte_be_to_cpu_32(init_val);
> > + return init_val;
> > +}
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
> > +
> > +#endif /* _RTE_HASH_XOR_H_ */
>
> --
> Regards,
> Vladimir
>
>
--0000000000001435bb05f5275cc5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Got it. Will fix. Thanks!</div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 20, 2023 at 12:10 PM =
Medvedkin, Vladimir <<a href=3D"mailto:vladimir.medvedkin@intel.com">vla=
dimir.medvedkin@intel.com</a>> wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Hi Bill,<br>
<br>
On 15/02/2023 11:06, Bili Dong wrote:<br>
> An XOR32 hash is needed in the Software Switch (SWX) Pipeline for its<=
br>
> use case in P4. We implement it in this patch so it could be easily<br=
>
> registered in the pipeline later.<br>
><br>
> Signed-off-by: Bili Dong <<a href=3D"mailto:qobilidop@gmail.com" ta=
rget=3D"_blank">qobilidop@gmail.com</a>><br>
> ---<br>
> +static inline uint32_t<br>
> +rte_hash_xor(const void *data, uint32_t data_len, uint32_t init_val)<=
br>
> +{<br>
> +=C2=A0 =C2=A0 =C2=A0uint32_t i;<br>
> +=C2=A0 =C2=A0 =C2=A0uintptr_t pd =3D (uintptr_t) data;<br>
> +=C2=A0 =C2=A0 =C2=A0init_val =3D rte_cpu_to_be_32(init_val);<br>
> +<br>
> +=C2=A0 =C2=A0 =C2=A0for (i =3D 0; i < data_len / 4; i++) {<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0init_val ^=3D *(const=
uint32_t *)pd;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pd +=3D 4;<br>
> +=C2=A0 =C2=A0 =C2=A0}<br>
> +<br>
> +=C2=A0 =C2=A0 =C2=A0if (data_len & 0x2) {<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0init_val ^=3D *(const=
uint32_t *)pd & LEFT16b_MASK;<br>
<br>
Here you are reading 2 bytes after the data buffer, which can sometimes <br=
>
lead to segfault. I think it would be better just to:<br>
<br>
init_val ^=3D *(const uint16_t *)pd << 16;<br>
<br>
The same with the section bellow<br>
<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pd +=3D 2;<br>
> +=C2=A0 =C2=A0 =C2=A0}<br>
> +<br>
> +=C2=A0 =C2=A0 =C2=A0if (data_len & 0x1)<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0init_val ^=3D *(const=
uint32_t *)pd & LEFT8b_MASK;<br>
> +<br>
> +=C2=A0 =C2=A0 =C2=A0init_val =3D rte_be_to_cpu_32(init_val);<br>
> +=C2=A0 =C2=A0 =C2=A0return init_val;<br>
> +}<br>
> +<br>
> +#ifdef __cplusplus<br>
> +}<br>
> +#endif<br>
> +<br>
> +#endif /* _RTE_HASH_XOR_H_ */<br>
<br>
-- <br>
Regards,<br>
Vladimir<br>
<br>
</blockquote></div>
--0000000000001435bb05f5275cc5--