From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 65EAAA05D3 for ; Tue, 23 Apr 2019 13:49:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 877315F3C; Tue, 23 Apr 2019 13:49:22 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 374605F1F; Tue, 23 Apr 2019 13:49:21 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2019 04:49:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,385,1549958400"; d="scan'208";a="142882529" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga008.fm.intel.com with ESMTP; 23 Apr 2019 04:49:19 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by IRSMSX107.ger.corp.intel.com (163.33.3.99) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 23 Apr 2019 12:49:18 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.31]) by irsmsx111.ger.corp.intel.com ([169.254.2.85]) with mapi id 14.03.0415.000; Tue, 23 Apr 2019 12:49:18 +0100 From: "Ananyev, Konstantin" To: Akhil Goyal , "dev@dpdk.org" CC: "Nicolau, Radu" , "Zhang, Roy Fan" , "stable@dpdk.org" Thread-Topic: [PATCH] examples/ipsec-secgw: fix pool usage for security session Thread-Index: AQHU+RrXGGFe3qtDY0WNuF8PRJXv4KZJoKww Date: Tue, 23 Apr 2019 11:49:17 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580148A9B044@irsmsx105.ger.corp.intel.com> References: <20190422143942.26956-1-akhil.goyal@nxp.com> In-Reply-To: <20190422143942.26956-1-akhil.goyal@nxp.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNmFhZTUyNzAtMjlhZC00N2JkLWJjOTYtYTMyNmVlOTE1MzAyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiKzB4c2lnVHM0dDZIT0c4WmNPbVBWM1wvbkZnN0NuM1ljZFF6ZTU1aXc3dElhVXhaU1ViRG9VcHRkY3lyZkZuYmkifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: fix pool usage for security session X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190423114917.Jc3pubK0MOQlz5gzhm-f3ojO-txlydkGyqsUGZVbEcg@z> Hi Akhil, > Currently, two separate mempools are being used for creating crypto > sessions and its private data. > crypto sessions are created and initialized separately, so a separate > mempool is passed to each API, but in case of security sessions, where > only one API create and initialize the private data as well. > So if session mempool is passed to create a security session, the > mempool element size is not sufficient enough to hold the private > data as well. > As a perfect solution, the security session create API should take 2 > mempools for header and private data and initiatlize accordingly, > but that would mean an API breakage, which will be done in the next > release cycle. So introducing this patch as a workaround to resolve this > issue. >=20 > Fixes: 261bbff75e34 ("examples: use separate crypto session mempools") > Cc: roy.fan.zhang@intel.com > Cc: stable@dpdk.org >=20 > Signed-off-by: Akhil Goyal > --- > examples/ipsec-secgw/ipsec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) >=20 > diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c > index 4352cb842..7b8533077 100644 > --- a/examples/ipsec-secgw/ipsec.c > +++ b/examples/ipsec-secgw/ipsec.c > @@ -102,7 +102,7 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ip= sec_sa *sa) > set_ipsec_conf(sa, &(sess_conf.ipsec)); >=20 > sa->sec_session =3D rte_security_session_create(ctx, > - &sess_conf, ipsec_ctx->session_pool); > + &sess_conf, ipsec_ctx->session_priv_pool); > if (sa->sec_session =3D=3D NULL) { > RTE_LOG(ERR, IPSEC, > "SEC Session init failed: err: %d\n", ret); > @@ -117,7 +117,7 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ip= sec_sa *sa) > int ret =3D 0; >=20 > sa->sec_session =3D rte_security_session_create(ctx, > - &sess_conf, ipsec_ctx->session_pool); > + &sess_conf, ipsec_ctx->session_priv_pool); > if (sa->sec_session =3D=3D NULL) { > RTE_LOG(ERR, IPSEC, > "SEC Session init failed: err: %d\n", ret); > -- Looks good to me , but seems incomplete. I think we also need to: static int32_t cryptodevs_init(void) { ... /* create session pools for eth devices that implement security */ RTE_ETH_FOREACH_DEV(port_id) { if ((enabled_port_mask & (1 << port_id)) && rte_eth_dev_get_sec_ctx(port_id)) { int socket_id =3D rte_eth_dev_socket_id(port_id); - if (!socket_ctx[socket_id].session_pool) { + if (!socket_ctx[socket_id].session_priv_pool) { char mp_name[RTE_MEMPOOL_NAMESIZE]; struct rte_mempool *sess_mp; snprintf(mp_name, RTE_MEMPOOL_NAMESIZE, "sess_mp_%u", socket_id); sess_mp =3D rte_mempool_create(mp_name, (CDEV_MP_NB_OBJS * 2), max_sess_sz, CDEV_MP_CACHE_SZ, 0, NULL, NULL, NULL, NULL, socket_id, 0); if (sess_mp =3D=3D NULL) rte_exit(EXIT_FAILURE, "Cannot create session pool= " "on socket %d\n", socket_id= ); else printf("Allocated session pool " "on socket %d\n", socket_id= ); - socket_ctx[socket_id].session_pool =3D sess= _mp; + socket_ctx[socket_id].session_priv_pool =3D= sess_mp; } } } Konstantin > 2.17.1