DPDK patches and discussions
 help / color / mirror / Atom feed
From: Didier Pallard <didier.pallard@6wind.com>
To: Akhil Goyal <gakhil@marvell.com>,
	Fan Zhang <fanzhang.oss@gmail.com>,
	Olivier Matz <olivier.matz@6wind.com>
Cc: dev@dpdk.org
Subject: [RFC] Fix cryptodev socket id for devices on unknown NUMA node
Date: Tue, 17 Jan 2023 11:16:46 +0100	[thread overview]
Message-ID: <20230117101646.2521875-1-didier.pallard@6wind.com> (raw)

Since DPDK 22.11 and below commit:
https://git.dpdk.org/dpdk/commit/?id=7dcd73e37965ba0bfa430efeac362fe183ed0ae2
rte_cryptodev_socket_id() could return an incorrect value of 255.
Problem has been seen during configuration of the qat device
on an Atom C3000 architecture. On this arch, PCI is not depending on
any numa socket, causing device numa_node to be equal to SOCKET_ID_ANY.
Due to incorrect cast to uint8_t, this value is stored as 255
in cryptodev structure and returned as such by rte_cryptodev_socket_id()
function.

Below patch proposes one way to fix the issue: casting to a signed int8_t
instead of the uint8_t. (it could also be casted to an int, that is the
usual type for numa_node, but this may break the ABI). This makes the
SOCKET_ID_ANY being propagated up to the user.
Another solution could be to always store a valid numa_node in this field
instead of just copying the numa_node field of the device, but this
requires to fix most crypto PMDs, that are currently just copying the
device value.

What is the preferred solution?

---
cryptodev: fix numa_node type

Since below commit, numa_node can be set to SOCKET_ID_ANY.
Do not cast numa_node to an unsigned uint8, else SOCKET_ID_ANY
is converted to 255, causing rte_cryptodev_socket_id to return
an incorrect value.

Fixes: 7dcd73e37965 ("drivers/bus: set device NUMA node to unknown by default")
Signed-off-by: Didier Pallard <didier.pallard@6wind.com>
---
 lib/cryptodev/cryptodev_pmd.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 0020102eb7db..db4745d620f4 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -64,8 +64,8 @@ struct rte_cryptodev_pmd_init_params {
 struct rte_cryptodev_data {
 	/** Device ID for this instance */
 	uint8_t dev_id;
-	/** Socket ID where memory is allocated */
-	uint8_t socket_id;
+	/** Socket ID of the device */
+	int8_t socket_id;
 	/** Unique identifier name */
 	char name[RTE_CRYPTODEV_NAME_MAX_LEN];
 
-- 
2.30.2


             reply	other threads:[~2023-01-17 10:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-17 10:16 Didier Pallard [this message]
2023-01-17 11:32 ` Morten Brørup
2023-01-17 13:03   ` Bruce Richardson
2023-01-17 13:36     ` Morten Brørup
2023-01-17 13:59       ` Bruce Richardson
2023-01-18  8:52         ` Morten Brørup

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=20230117101646.2521875-1-didier.pallard@6wind.com \
    --to=didier.pallard@6wind.com \
    --cc=dev@dpdk.org \
    --cc=fanzhang.oss@gmail.com \
    --cc=gakhil@marvell.com \
    --cc=olivier.matz@6wind.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).