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 D35F6A0093;
Wed, 31 Aug 2022 18:23:26 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 9A62E40F17;
Wed, 31 Aug 2022 18:23:25 +0200 (CEST)
Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com
[209.85.214.177])
by mails.dpdk.org (Postfix) with ESMTP id 6E64140395
for <dev@dpdk.org>; Wed, 31 Aug 2022 18:23:23 +0200 (CEST)
Received: by mail-pl1-f177.google.com with SMTP id v5so8382611plo.9
for <dev@dpdk.org>; Wed, 31 Aug 2022 09:23:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:from:to:cc;
bh=Z0siFSvFl1THjq9KKFeEd6wTOrmACfykNeZp520ufU4=;
b=XdQKDDA7Y4TUpWWiIlPO6o3KmD0MJJS4b/g1sDh8KzYJzrUzE96QeiUTziC3ohM+Tk
EoO5a3KyZRgxKkN2ngvevuf/UhNaDDIaZ0fGDeeoZd9d3niD/Pn1vZc5ew/sK84v0cT3
M0BqogkneOlGbvM6Ah8QvkZ9IABp7uhQt/566dAMrzP5xUiuySFZJek1/K/GL1qGmVvV
GbdwPrdR6AT3XIuS+TC8lPxUi9utOeuKRjaTOcwmKMJLfVcZOTWpqc9TXZNMKoZ9GOII
27QxqwvPLkx3IqyAPqPqz9HlUc2+Io26yRrQs2bzD4LYaOM5djtwSlfyVFX/HTlxpv1P
jr3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc;
bh=Z0siFSvFl1THjq9KKFeEd6wTOrmACfykNeZp520ufU4=;
b=jY0WoYV5vHBXPNX9BQJX6XKT9iGaGDBfsRt4CaujatQOpnJ9rGptiz2LFV1EYdUIE8
cMAnXy0woCMy1dKuRYyl1KhkV1AOnWCmUo8ngs4CtA0uoXrOmkgBNfzwHOMl1c+FCnX0
aJ/dov3JBGhC1KK2g7oryWVWX79lE1jeesETfx5iUoGFPNU8uKFjtwncbMyzVbEpbiL0
DCE1AWCbVyP6eLVChwd+j3JayUtA1eMDXzUvrBCCHPyrvPnd9DpCJz2bJuIQCbOMNfJk
WdUmDLBzuIRGlG382rhCugsWZLZP2fxHkRR0cZzClp/ldiieVgbJzdWcSek5Ap9BTqUl
S4nQ==
X-Gm-Message-State: ACgBeo1mf+4FM+NCjOirN+T3vnzf3NGvpSG+qulEfKqQUIjZa8VVSyYO
5R6b1r43gwvCCgVOGxj6Fikt3w==
X-Google-Smtp-Source: AA6agR7RzYD4lhNb/4KWdeASAb3ViIVtxIgVyuZ3AsTg/1L9C4HoxCtKb3mMFXDroX6zKxYEqt4tuA==
X-Received: by 2002:a17:902:d509:b0:16f:1e1:2063 with SMTP id
b9-20020a170902d50900b0016f01e12063mr26339712plg.131.1661963002348;
Wed, 31 Aug 2022 09:23:22 -0700 (PDT)
Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218])
by smtp.gmail.com with ESMTPSA id
u8-20020a170903124800b00174f61a7d09sm5630619plh.247.2022.08.31.09.23.21
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 31 Aug 2022 09:23:22 -0700 (PDT)
Date: Wed, 31 Aug 2022 09:23:20 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH V2 0/6] pipeline: make the hash function configurable
per table
Message-ID: <20220831092320.64a3a42a@hermes.local>
In-Reply-To: <20220819195225.1483020-1-cristian.dumitrescu@intel.com>
References: <20220818114449.1408226-1-cristian.dumitrescu@intel.com>
<20220819195225.1483020-1-cristian.dumitrescu@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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
On Fri, 19 Aug 2022 19:52:19 +0000
Cristian Dumitrescu <cristian.dumitrescu@intel.com> wrote:
> 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%.
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.
As in:
if (likely(hash_func == crc32_hash))
crc32_hash(x, y)
else
(*hash_func)(x, y)
This was done in Linux kernel because of the overhead of the Spectre/Meltdown
mitigation's, but could apply more generally in DPDK.