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 C190B43251; Tue, 31 Oct 2023 10:36:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6E5D24068E; Tue, 31 Oct 2023 10:36:56 +0100 (CET) Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by mails.dpdk.org (Postfix) with ESMTP id 4882A4026C for ; Tue, 31 Oct 2023 10:36:38 +0100 (CET) Received: by mail-pg1-f175.google.com with SMTP id 41be03b00d2f7-5b7f3f470a9so3637851a12.0 for ; Tue, 31 Oct 2023 02:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meaningfulname-net.20230601.gappssmtp.com; s=20230601; t=1698744997; x=1699349797; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GNiV7JxBSd74+BtidamXmT4vedqhtN4PKwkILkZAEKg=; b=Bn8tmPtAm0GCNFDV6GPlP+Qo9JxMArPjib78mtM1Rg80E7OVH9rLrYyxUc86rs0vXf zgWuwYKyMQj9pspa9ZjhV8tXWo7Vh+txJcmKI4eYxWfi0GB9/bF+Jo+WqrrMsmBoCgDU c5djyBZK6m4j8ci6g7C6mbty0TITM29+mMXBSGc08BzrwjHwI55YO/wdF5ZufrWU3aqa 11EufnphHOf19uRLLKL0sWtQMK/30QFRsi6iVpcWdncv+57GdRkI5i8JHhAzBK0cgmKE SGwZsxsqyFGFXuIm8wAAdsE8B2lkZm7vdOmRBqpO2k2e6Cw7MJYpZflOfapfXglBbUYX X8cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698744997; x=1699349797; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GNiV7JxBSd74+BtidamXmT4vedqhtN4PKwkILkZAEKg=; b=RVARgGiM9ulMI2wyjS7wjbTZJT+liOZK3SEft+p9qjtKWbaaAu5m/mWJP3chLcWJO/ n2wPMfEwqVKssM+IjY3PEqIhDNsu4dkggDx4yYc+kw1KpqpOxcBmFPy55WWypY/tMVjN wXY8vP7hKNENFMW0hnnL1PJ24lgsVH+1TyvJqKLS8/skxNEBTFXAzKD+DopQlFjIHYpV aeoPHz+u2AGf0BryMYgqu7YpDw+lOIqiZZI3pn9b9GCAY1U3ZlxRHdV451/DPRNdlhkJ 1mkXYvi90cvR9zKg4P44mYXGP+p5Cx1SRS0o8tven6Okll+ldupM4h29Lz6G7OcEzACA rjxA== X-Gm-Message-State: AOJu0YzZMeXPQZgZfnN67hzQWnzqee1yzJmL6JEXtYpaMXO3oAwS5Ise DlZV9Zr/34Ia3UljNblTeE0NLr8jvfWbaVBItdSxaBo++QvRU5MrAMY= X-Google-Smtp-Source: AGHT+IEbMGGnzThcAPNtGRTqx5TRSVoEbxLwepqIjryACPeYfr7i8VD/L7/98JSb0QKyx+ZJLUNyWAM4Uj9DWo5hyE0= X-Received: by 2002:a17:90b:4f8e:b0:280:74fc:ac2c with SMTP id qe14-20020a17090b4f8e00b0028074fcac2cmr3711428pjb.13.1698744997355; Tue, 31 Oct 2023 02:36:37 -0700 (PDT) MIME-Version: 1.0 References: <20230925201128.861-1-gazmarsh@meaningfulname.net> <64c6794e-69ef-4469-a596-32cd9d70d0bd@yandex.ru> In-Reply-To: <64c6794e-69ef-4469-a596-32cd9d70d0bd@yandex.ru> From: Garry Marshall Date: Tue, 31 Oct 2023 09:36:25 +0000 Message-ID: Subject: Re: [PATCH] ipsec: use sym_session_opaque_data for RTE_SECURITY_TYPE_CPU_CRYPTO To: Konstantin Ananyev Cc: dev@dpdk.org, vladimir.medvedkin@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Hi Konstantin, Akhil, The patch is based on an issue I encountered when using the CPU_CRYPTO support - I was having problems where the ipsec session lookup was failing / was inconsistent. Examining the code in DPDK and looking for the use of RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO I could see a reasonably consistent pattern where if TYPE_NONE or TYPE_CPU_CRYPTO was set - then the code was making use of ss->crypto.ses instead of ss->security.ses. For example - see examples/ipsec-secgw.c where the one_session_free function has the following code: if (ips->type =3D=3D RTE_SECURITY_ACTION_TYPE_NONE || ips->type =3D=3D RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO) { /* Session has not been created */ if (ips->crypto.ses =3D=3D NULL) return 0; ret =3D rte_cryptodev_sym_session_free(ips->crypto.dev_id, ips->crypto.ses); } else { /* Session has not been created */ if (ips->security.ctx =3D=3D NULL || ips->security.ses =3D=3D NULL) return 0; ret =3D rte_security_session_destroy(ips->security.ctx, ips->security.ses); } And similarly - if we look at the session_check function in lib/ipsec/ses.c= : if (ss->type =3D=3D RTE_SECURITY_ACTION_TYPE_NONE || ss->type =3D=3D RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO) { if (ss->crypto.ses =3D=3D NULL) return -EINVAL; } else { if (ss->security.ses =3D=3D NULL) return -EINVAL; if ((ss->type =3D=3D RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO || ss->type =3D=3D RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) && ss->security.ctx =3D=3D NULL) return -EINVAL; } Without the patch in rte_ipsec_session_prepare - for the RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO type, then ss->crypto.ses will not be set. Regards, Garry. On Tue, Oct 31, 2023 at 1:09=E2=80=AFAM Konstantin Ananyev wrote: > > > > > > > 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 *s= s) > > > > ss->pkt_func =3D fp; > > > > - if (ss->type =3D=3D RTE_SECURITY_ACTION_TYPE_NONE) > > + if (ss->type =3D=3D RTE_SECURITY_ACTION_TYPE_NONE || > > + ss->type =3D=3D RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO) > > rte_cryptodev_sym_session_opaque_data_set(ss->crypto.ses, > > (uintptr_t)ss); > > else > > -- > > 2.39.2