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 735E4A0032;
	Thu,  1 Sep 2022 10:11:25 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 5B22040684;
	Thu,  1 Sep 2022 10:11:25 +0200 (CEST)
Received: from smartserver.smartsharesystems.com
 (smartserver.smartsharesystems.com [77.243.40.215])
 by mails.dpdk.org (Postfix) with ESMTP id 2F31B40395
 for <dev@dpdk.org>; Thu,  1 Sep 2022 10:11:24 +0200 (CEST)
Content-class: urn:content-classes:message
Subject: RE: [PATCH V2 0/6] pipeline: make the hash function configurable per
 table
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 1 Sep 2022 10:11:21 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D872DB@smartserver.smartshare.dk>
In-Reply-To: <20220831092320.64a3a42a@hermes.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PATCH V2 0/6] pipeline: make the hash function configurable per
 table
Thread-Index: Adi9VgDlljcqVne8S/G8Wyt7nSNqggAdqT0Q
References: <20220818114449.1408226-1-cristian.dumitrescu@intel.com>
 <20220819195225.1483020-1-cristian.dumitrescu@intel.com>
 <20220831092320.64a3a42a@hermes.local>
From: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>,
 "Cristian Dumitrescu" <cristian.dumitrescu@intel.com>
Cc: <dev@dpdk.org>
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

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, 31 August 2022 18.23
> Subject: Re: [PATCH V2 0/6] pipeline: make the hash function
> configurable per table
>=20
> On Fri, 19 Aug 2022 19:52:19 +0000
> Cristian Dumitrescu <cristian.dumitrescu@intel.com> wrote:
>=20
> > Also, since this flexibility has some performance cost, this patch
> set
> > also introduces key comparison functions specialized for each key
> size
> > value. Since the key size is fixed for each table, the key =
comparison
> > function can be selected at initialization as opposed to using a
> > generic function that can handle any key size. This strategy result
> in
> > a performance improvement for the table lookup operation of around
> 5%.
>=20
> I wonder if DPDK should start to adopt the Linux kernel optimizations
> around indirect calls. For most all cases, the function pointer will =
be
> a certain value and the cpu can do direct rather than indirect call.
>=20
> As in:
>=20
>      if (likely(hash_func =3D=3D crc32_hash))
>             crc32_hash(x, y)
>      else
>             (*hash_func)(x, y)
>=20
> This was done in Linux kernel because of the overhead of the
> Spectre/Meltdown
> mitigation's, but could apply more generally in DPDK.

+1 to that!

Along the very same lines, I remember reading on LWN about the Linux =
kernel using some magic to avoid function pointers, or to install =
optimized functions: At locations in the code where multiple variants of =
a function could be used, the address of the correct/optimized function =
is written directly into those locations in the code at startup. I =
didn't read the article in depth back then, and I can't find it now. =
Perhaps you know what I'm referring to, Stephen? I wonder if that also =
might be relevant for DPDK.