From: Stephen Hemminger <stephen@networkplumber.org>
To: Tyler Retzlaff <roretzla@linux.microsoft.com>
Cc: David Marchand <david.marchand@redhat.com>,
dev@dpdk.org, Yipeng Wang <yipeng1.wang@intel.com>,
Sameh Gobriel <sameh.gobriel@intel.com>,
Bruce Richardson <bruce.richardson@intel.com>,
Vladimir Medvedkin <vladimir.medvedkin@intel.com>
Subject: Re: [PATCH] hash: make gfni stubs inline
Date: Tue, 5 Mar 2024 10:44:44 -0800 [thread overview]
Message-ID: <20240305104444.24b97e4d@hermes.local> (raw)
In-Reply-To: <20240305175300.GC18937@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Tue, 5 Mar 2024 09:53:00 -0800
Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
> On Tue, Mar 05, 2024 at 11:14:45AM +0100, David Marchand wrote:
> > On Mon, Mar 4, 2024 at 7:45 PM Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > >
> > > This reverts commit 07d836e5929d18ad6640ebae90dd2f81a2cafb71.
> > >
> > > Tyler found build issues with MSVC and the thash gfni stubs.
> > > The problem would be link errors from missing symbols.
> >
> > Trying to understand this link error.
> > Does it come from the fact that rte_thash_gfni/rte_thash_gfni_bulk
> > declarations are hidden under RTE_THASH_GFNI_DEFINED in
> > rte_thash_gfni.h?
> >
> > If so, why not always expose those two symbols unconditionnally and
> > link with the stub only when ! RTE_THASH_GFNI_DEFINED.
>
> So I don't have a lot of background of this lib.
>
> I think we understand that we can't conditionally expose symbols. That's
> what windows was picking up because it seems none of our CI's ever end
> up with RTE_THASH_GFNI_DEFINED but my local test system did and failed.
> (my experiments showed that Linux would complain too if it was defined)
>
> If we always expose the symbols then as you point out we have to
> conditionally link with the stub otherwise the inline (non-stub) will be
> duplicate and build / link will fail.
>
> I guess the part I don't understand with your suggestion is how we would
> conditionally link with just the stub? We have to link with rte_hash to
> get the rest of hash and the stub. I've probably missed something here.
>
> Since we never had a release exposing the new symbols introduced by
> Stephen in question my suggestion was that we just revert for 24.03 so
> we don't end up with an ABI break later if we choose to solve the
> problem without exports.
>
> I don't know what else to do, but I think we need to decide for 24.03.
>
> ty
Another option would be introduce dead code stubs all the time.
Then have inline wrapper that redirect to the dead stub if needed.
Something like:
From 7bb972d342e939200f8f993a9074b20794941f6a Mon Sep 17 00:00:00 2001
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 5 Mar 2024 10:42:48 -0800
Subject: [PATCH] hash: rename GFNI stubs
Make the GFNI stub functions always built. This solves the conditional
linking problem. If GFNI is available, they will never get used.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/hash/rte_thash_gfni.c | 11 +++++------
lib/hash/rte_thash_gfni.h | 23 ++++++++++++++++++-----
lib/hash/version.map | 9 +++++++--
3 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/lib/hash/rte_thash_gfni.c b/lib/hash/rte_thash_gfni.c
index f1525f9838de..de67abb8b211 100644
--- a/lib/hash/rte_thash_gfni.c
+++ b/lib/hash/rte_thash_gfni.c
@@ -4,18 +4,18 @@
#include <stdbool.h>
+#include <rte_common.h>
#include <rte_log.h>
#include <rte_thash_gfni.h>
-#ifndef RTE_THASH_GFNI_DEFINED
-
RTE_LOG_REGISTER_SUFFIX(hash_gfni_logtype, gfni, INFO);
#define RTE_LOGTYPE_HASH hash_gfni_logtype
#define HASH_LOG(level, ...) \
RTE_LOG_LINE(level, HASH, "" __VA_ARGS__)
+__rte_internal
uint32_t
-rte_thash_gfni(const uint64_t *mtrx __rte_unused,
+___rte_thash_gfni(const uint64_t *mtrx __rte_unused,
const uint8_t *key __rte_unused, int len __rte_unused)
{
static bool warned;
@@ -29,8 +29,9 @@ rte_thash_gfni(const uint64_t *mtrx __rte_unused,
return 0;
}
+__rte_internal
void
-rte_thash_gfni_bulk(const uint64_t *mtrx __rte_unused,
+___rte_thash_gfni_bulk(const uint64_t *mtrx __rte_unused,
int len __rte_unused, uint8_t *tuple[] __rte_unused,
uint32_t val[], uint32_t num)
{
@@ -47,5 +48,3 @@ rte_thash_gfni_bulk(const uint64_t *mtrx __rte_unused,
for (i = 0; i < num; i++)
val[i] = 0;
}
-
-#endif
diff --git a/lib/hash/rte_thash_gfni.h b/lib/hash/rte_thash_gfni.h
index eed55fc86c86..1cb61cf39675 100644
--- a/lib/hash/rte_thash_gfni.h
+++ b/lib/hash/rte_thash_gfni.h
@@ -9,7 +9,16 @@
extern "C" {
#endif
-#include <rte_log.h>
+#include <rte_common.h>
+/*
+ * @internal
+ * Stubs defined for use when GFNI is not available
+ */
+uint32_t
+___rte_thash_gfni(const uint64_t *mtrx, const uint8_t *key, int len);
+void
+___rte_thash_gfni_bulk(const uint64_t *mtrx, int len, uint8_t *tuple[],
+ uint32_t val[], uint32_t num);
#ifdef RTE_ARCH_X86
@@ -18,10 +27,8 @@ extern "C" {
#endif
#ifndef RTE_THASH_GFNI_DEFINED
-
/**
* Calculate Toeplitz hash.
- * Dummy implementation.
*
* @param m
* Pointer to the matrices generated from the corresponding
@@ -34,7 +41,10 @@ extern "C" {
* Calculated Toeplitz hash value.
*/
uint32_t
-rte_thash_gfni(const uint64_t *mtrx, const uint8_t *key, int len);
+rte_thash_gfni(const uint64_t *mtrx, const uint8_t *key, int len)
+{
+ return ___rte_thash_gfni(mtrx, key, len);
+}
/**
* Bulk implementation for Toeplitz hash.
@@ -55,7 +65,10 @@ rte_thash_gfni(const uint64_t *mtrx, const uint8_t *key, int len);
*/
void
rte_thash_gfni_bulk(const uint64_t *mtrx, int len, uint8_t *tuple[],
- uint32_t val[], uint32_t num);
+ uint32_t val[], uint32_t num)
+{
+ return ___rte_thash_gfni_bulk(mtrx, len, tuple, val);
+}
#endif /* RTE_THASH_GFNI_DEFINED */
diff --git a/lib/hash/version.map b/lib/hash/version.map
index 6b2afebf6b46..942e2998578f 100644
--- a/lib/hash/version.map
+++ b/lib/hash/version.map
@@ -41,10 +41,15 @@ DPDK_24 {
rte_thash_get_gfni_matrices;
rte_thash_get_helper;
rte_thash_get_key;
- rte_thash_gfni;
- rte_thash_gfni_bulk;
rte_thash_gfni_supported;
rte_thash_init_ctx;
local: *;
};
+
+INTERNAL {
+ global:
+
+ ___rte_thash_gfni;
+ ___rte_thash_gfni_bulk;
+};
--
2.43.0
next prev parent reply other threads:[~2024-03-05 18:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 18:45 [PATCH] hash: make gfni stubs inline Stephen Hemminger
2024-03-05 3:07 ` [PATCH v2] hash: make GFNI stubs inline (again) Stephen Hemminger
2024-03-05 3:58 ` Tyler Retzlaff
2024-03-06 17:22 ` Thomas Monjalon
2024-03-05 10:14 ` [PATCH] hash: make gfni stubs inline David Marchand
2024-03-05 17:53 ` Tyler Retzlaff
2024-03-05 18:44 ` Stephen Hemminger [this message]
2024-03-07 10:32 ` David Marchand
2024-03-07 16:49 ` Stephen Hemminger
2024-03-06 21:47 ` [PATCH v3] hash: put GFNI stubs back Stephen Hemminger
2024-03-07 1:36 ` Stephen Hemminger
2024-03-07 11:05 ` David Marchand
2024-03-07 17:36 ` Tyler Retzlaff
2024-03-07 17:59 ` David Marchand
2024-03-07 20:23 ` Stephen Hemminger
2024-03-07 19:14 ` [PATCH v4] " Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240305104444.24b97e4d@hermes.local \
--to=stephen@networkplumber.org \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=roretzla@linux.microsoft.com \
--cc=sameh.gobriel@intel.com \
--cc=vladimir.medvedkin@intel.com \
--cc=yipeng1.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.