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 F011A43249; Tue, 31 Oct 2023 02:09:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6B30A400EF; Tue, 31 Oct 2023 02:09:02 +0100 (CET) Received: from forward102a.mail.yandex.net (forward102a.mail.yandex.net [178.154.239.85]) by mails.dpdk.org (Postfix) with ESMTP id 8F2F5400D7 for ; Tue, 31 Oct 2023 02:09:00 +0100 (CET) Received: from mail-nwsmtp-smtp-production-main-39.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-39.vla.yp-c.yandex.net [IPv6:2a02:6b8:c0d:31b:0:640:fdf8:0]) by forward102a.mail.yandex.net (Yandex) with ESMTP id E003F60AF4; Tue, 31 Oct 2023 04:08:59 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-39.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id v8JxhM8DdqM0-P1J3Qb7E; Tue, 31 Oct 2023 04:08:59 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1698714539; bh=+4yBXcO3MVQI3OaFXQTiTob072KiiFi1MxuAGbjU57k=; h=From:Subject:In-Reply-To:Cc:Date:References:To:Message-ID; b=rEBWzVH7xxGxjBfTZp00fwBzLHhbK4UORRP5Qjdnq+Zlt4V5FhomzhgH2KO57ywWz bmjwNNSSkgJmjzdD8TcQQtHV2Ve4U2DJ6mviCnFNJLQh+G8ZPBjJCVh5nUYh8J5txm /1ig0hi1TFTQw3NWlz50LEhkuSm+PUZx8qsFx4+k= Authentication-Results: mail-nwsmtp-smtp-production-main-39.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <64c6794e-69ef-4469-a596-32cd9d70d0bd@yandex.ru> Date: Tue, 31 Oct 2023 01:08:57 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: gazmarsh@meaningfulname.net Cc: dev@dpdk.org, konstantin.v.ananyev@yandex.ru, vladimir.medvedkin@intel.com References: <20230925201128.861-1-gazmarsh@meaningfulname.net> Subject: Re: [PATCH] ipsec: use sym_session_opaque_data for RTE_SECURITY_TYPE_CPU_CRYPTO Content-Language: ru-RU, en-US From: Konstantin Ananyev In-Reply-To: <20230925201128.861-1-gazmarsh@meaningfulname.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > > > ipsec related processing in dpdk makes use of the crypto.ses opaque > data pointer. This patch updates rte_ipsec_session_prepare to set > ss->crypto.ses in the RTE_SECURITY_TYPE_CPU_CRYPTO case. Hmm.. not sure why we need to do that for CPU_CRYPTO? As I remember CPU_CRYPTO is synchronous operation and before calling rte_ipsec_pkt_cpu_prepare() should already know ipsec session these packets belong to. Can you probably explain the logic behind this patch a bit more? Konstantin > > Signed-off-by: Garry Marshall > --- > lib/ipsec/ses.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lib/ipsec/ses.c b/lib/ipsec/ses.c > index d9ab1e6d2b..29eb5ff6ca 100644 > --- a/lib/ipsec/ses.c > +++ b/lib/ipsec/ses.c > @@ -44,7 +44,8 @@ rte_ipsec_session_prepare(struct rte_ipsec_session *ss) > > ss->pkt_func = fp; > > - if (ss->type == RTE_SECURITY_ACTION_TYPE_NONE) > + if (ss->type == RTE_SECURITY_ACTION_TYPE_NONE || > + ss->type == RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO) > rte_cryptodev_sym_session_opaque_data_set(ss->crypto.ses, > (uintptr_t)ss); > else > -- > 2.39.2