From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C75AC423FB; Tue, 17 Jan 2023 11:16:59 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 724C340151; Tue, 17 Jan 2023 11:16:59 +0100 (CET) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by mails.dpdk.org (Postfix) with ESMTP id 496C9400D4 for ; Tue, 17 Jan 2023 11:16:58 +0100 (CET) Received: by mail-wm1-f42.google.com with SMTP id q8so10012152wmo.5 for ; Tue, 17 Jan 2023 02:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=XtW8ZDo2kcc2A7BDE4rC8D8tWtcaew3TI8576rfjrKE=; b=A4v+b0hMEuCwAa0+7byHs9AyiNrL1RhzJ+q0W3OrG0PZKjRAOvMnELAbj/5TdrpGKb ov6SbNszADB6eLNoRtAFSna/gSJlNNHSzZhmUPqI6+CEcMPgniAFagc1JX6KHdXcBCa0 Q7nO2nHk4kJdtbQgflMctlrVu55UmOlESw301q0jbL+SaEYyipVYXc2kCdBCcSTyVV2n h4rhUnIBDvEoNhrcF6KWNUbojCgoKAkeyOnPZc4d7/I9HPHYv2hIlI3c2Zcr4a65PnBp RiMifRrIumr3YQDkUEF8VPZ96+FTQLEp8279LJJRdNIe8XGR0dKRq7HF4lOjcMt3fMp1 Lccw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XtW8ZDo2kcc2A7BDE4rC8D8tWtcaew3TI8576rfjrKE=; b=RTWS8Kkv2iSqkElELvDtkq39xmk5V1+G6lYBl4E2Oh+5o2SpoqK84GkEmg5em233TV hYwxGiWpIFlIJHEm3MPlL/qAGdGbwz9gQE0PzmykLX+p1a9x4w4PMAZNkgdQd5+Q37Hl zZaYxKztpyUtfgwsCUfCAsGB+nPdUt16R2nuwa/gSYb7VYudSrIRW/pFBDblfloX/8y8 Fh4i3ML0Qr+vAzfal+yZHTgwMjqGbz497WBtEvBZnzesINRtaRSM3jGU4mLNEW9Neo/q hbrHyM+Pv2vesH4VSX1QQucNvLrn4t1jXPOhGNuHqSlYs2x7NQ+EjC3Yc24zxuQ7jznc 2yGA== X-Gm-Message-State: AFqh2kpKub804TpBeSYxeMVyU7PFnSAsSWKtmKbcz8mNlWa6474V2A7Y 04rH08uSJ8AMyxv9/WcgeSreFw== X-Google-Smtp-Source: AMrXdXsvhWs9NGYW0PnsWl4en6FNhUpp4bLhyhm83U0jxG2ZJ+QSCZQH5raxub4lYniBhUUQbF0THA== X-Received: by 2002:a05:600c:4f4a:b0:3db:5f1:53a5 with SMTP id m10-20020a05600c4f4a00b003db05f153a5mr2175527wmq.20.1673950617951; Tue, 17 Jan 2023 02:16:57 -0800 (PST) Received: from arion.dev.6wind.com ([185.13.181.2]) by smtp.gmail.com with ESMTPSA id q6-20020a05600c46c600b003d1f3e9df3csm43887051wmo.7.2023.01.17.02.16.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jan 2023 02:16:57 -0800 (PST) From: Didier Pallard To: Akhil Goyal , Fan Zhang , Olivier Matz 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 Message-Id: <20230117101646.2521875-1-didier.pallard@6wind.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 --- 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