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 A08DDA05D3 for ; Tue, 23 Apr 2019 15:32:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 222F65F28; Tue, 23 Apr 2019 15:32:11 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140073.outbound.protection.outlook.com [40.107.14.73]) by dpdk.org (Postfix) with ESMTP id B5FC94C95; Tue, 23 Apr 2019 15:32:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6c3JnTlimp5XmnSWyJqCDW8A6V8Sop8RwW0joN2Ambo=; b=gb460QhYdbFEOhPCB87kNE9+XLWkvjp8p3mWaTEjJpa6BK0M6jLTPIZt338PzXTI+Kdwy7TyuIE/kgQfgqURPK4VypkNWNebU6nFJwkCUQnT86svJTh6Cu65BhR97Y2NF1IvVps5F1LlmXl8derPFBUYeitmdOuWKVF+/MDTd6U= Received: from VI1PR04MB4893.eurprd04.prod.outlook.com (20.177.49.154) by VI1PR04MB5853.eurprd04.prod.outlook.com (20.178.204.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Tue, 23 Apr 2019 13:32:07 +0000 Received: from VI1PR04MB4893.eurprd04.prod.outlook.com ([fe80::98b0:84a6:1c08:57c7]) by VI1PR04MB4893.eurprd04.prod.outlook.com ([fe80::98b0:84a6:1c08:57c7%3]) with mapi id 15.20.1813.017; Tue, 23 Apr 2019 13:32:07 +0000 From: Akhil Goyal To: "Ananyev, Konstantin" , "Iremonger, Bernard" , "dev@dpdk.org" CC: "stable@dpdk.org" Thread-Topic: [PATCH v4 1/2] examples/ipsec-secgw: fix 1st packet dropped for inline crypto Thread-Index: AdT17cOXKHHL5EBLSxux3RG5b2/emQD1mybgAATSl4AAAA1EEA== Date: Tue, 23 Apr 2019 13:32:07 +0000 Message-ID: References: <2601191342CEEE43887BDE71AB9772580148A9B0D4@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580148A9B0D4@irsmsx105.ger.corp.intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0645663f-fc91-463e-9687-08d6c7f014b2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:VI1PR04MB5853; x-ms-traffictypediagnostic: VI1PR04MB5853: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(346002)(396003)(376002)(199004)(189003)(13464003)(68736007)(99286004)(7736002)(55016002)(14454004)(2501003)(97736004)(229853002)(305945005)(71190400001)(74316002)(6436002)(966005)(45080400002)(478600001)(66066001)(71200400001)(7696005)(76176011)(316002)(110136005)(26005)(33656002)(102836004)(186003)(4326008)(6116002)(3846002)(81156014)(6506007)(73956011)(8676002)(2906002)(486006)(476003)(86362001)(53546011)(66946007)(76116006)(8936002)(66476007)(81166006)(25786009)(66446008)(64756008)(66556008)(44832011)(6246003)(446003)(11346002)(256004)(5660300002)(6306002)(14444005)(53936002)(9686003)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR04MB5853; H:VI1PR04MB4893.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IGF13tximDVJBN2ShBRlIK3KhS/5zLZP/+AFuoieWrvzyw6ANcI6IzMN1IVA0oyEvuz9qtVNKLmGAqUl21P+aZwDB+QoOjZlZudW8dS5C6tbge5EtDpYwvqSTxLM6YNygjPPkC1CVlWXCYbMpPXMCrGrPlaO9Q8E0uItONkJkjagjgF2/tdLA+9LwjTEmHJOP7qK+HCot6EyVt4UojwuCSKLH+Si9SiNNiYEiKULi5WP9deZvBVEYwUHBfye8vLLzpGDfqTHHJt/NzD3nqCXOur+URgJOKM8IvDgy/Kb2mAIIZu+OJEk6ovuwPeVPwCXjOZrMByQqjpI9bW0dl2BakcDWYvWP2V5hItOxjnBqTx11T0KwTl9H1+hdPFh2IoLyOM1MnxgyVO8xVHNLYfqVZ+LMs4WtUgL101DradVmeA= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0645663f-fc91-463e-9687-08d6c7f014b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2019 13:32:07.1319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5853 Subject: Re: [dpdk-dev] [PATCH v4 1/2] examples/ipsec-secgw: fix 1st packet dropped for inline crypto 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: <20190423133207.Y1GOTRvt2C69cR0pvZiNLRpcQQIFlibWcqFPc5Wwq-M@z> Hi Konstantin, > Hi Akhil, >=20 > > > > > -----Original Message----- > > > From: Akhil Goyal > > > Sent: Thursday, April 18, 2019 7:21 PM > > > To: Bernard Iremonger ; dev@dpdk.org; > > > konstantin.ananyev@intel.com > > > Cc: stable@dpdk.org > > > Subject: RE: [PATCH v4 1/2] examples/ipsec-secgw: fix 1st packet drop= ped > for > > > inline crypto > > > > > > Hi Bernard, > > > > > > > - RTE_LOG_DP(DEBUG, IPSEC, "Create session for SA spi %u on > cryptodev " > > > > - "%u qp %u\n", sa->spi, > > > > - ipsec_ctx->tbl[cdev_id_qp].id, > > > > - ipsec_ctx->tbl[cdev_id_qp].qp); > > > > + if ((sa =3D=3D NULL) || (pool =3D=3D NULL)) > > > > + return -EINVAL; > > > > > > > > - if (sa->type !=3D RTE_SECURITY_ACTION_TYPE_NONE) { > > > > - struct rte_security_session_conf sess_conf =3D { > > > > + struct rte_security_session_conf sess_conf =3D { > > > > .action_type =3D sa->type, > > > > .protocol =3D RTE_SECURITY_PROTOCOL_IPSEC, > > > > {.ipsec =3D { > > > > @@ -90,247 +65,340 @@ create_session(struct ipsec_ctx *ipsec_ctx, > struct > > > > ipsec_sa *sa) > > > > } }, > > > > .crypto_xform =3D sa->xforms, > > > > .userdata =3D NULL, > > > > - > > > > }; > > > > > > > > - if (sa->type =3D=3D > > > RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL) > > > > { > > > > - struct rte_security_ctx *ctx =3D (struct rt= e_security_ctx *) > > > > - rte_cryptod= ev_get_sec_ctx( > > > > - ipsec_ctx->= tbl[cdev_id_qp].id); > > > > - > > > > - /* Set IPsec parameters in conf */ > > > > - set_ipsec_conf(sa, &(sess_conf.ipsec)); > > > > - > > > > - sa->sec_session =3D rte_security_session_cr= eate(ctx, > > > > - &sess_conf, ipsec_ctx->sess= ion_pool); > > > > - if (sa->sec_session =3D=3D NULL) { > > > > - RTE_LOG(ERR, IPSEC, > > > > - "SEC Session init failed: err: %d\n= ", ret); > > > > - return -1; > > > > - } > > > > - } else if (sa->type =3D=3D > RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) > > > { > > > > - struct rte_flow_error err; > > > > - struct rte_security_ctx *ctx =3D (struct rt= e_security_ctx *) > > > > - rte_eth_dev= _get_sec_ctx( > > > > - sa->portid)= ; > > > > - const struct rte_security_capability *sec_c= ap; > > > > - int ret =3D 0; > > > > - > > > > - sa->sec_session =3D rte_security_session_cr= eate(ctx, > > > > - &sess_conf, ipsec_ctx->sess= ion_pool); > > > > - if (sa->sec_session =3D=3D NULL) { > > > > - RTE_LOG(ERR, IPSEC, > > > > - "SEC Session init failed: err: %d\n= ", ret); > > > > - return -1; > > > > - } > > > > + if (sa->type =3D=3D > RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL) { > > > > + ctx =3D (struct rte_security_ctx *) > > > > + rte_eth_dev_get_sec_ctx(sa->portid)= ; > > > > > > This is breaking the lookaside mode. Ctx was retrieved using the ipse= c_ctx- > >tbl > > > struct rte_security_ctx *ctx =3D (struct rte_security_ctx *) > > > rte_cryptodev_get_sec_ctx( > > > ipsec_ctx->tbl[cdev_id_qp].id); > > > > > > I am looking into it, but I don't have time left to get it integrated= in RC2. So > this > > > has to be pushed to RC3 > > > > It looks like there are multiple issues in this patch wrt lookaside and= none cases. > Only the inline cases seem to be working. > > > > 1. the patch removes the cdev_mapping concept completely. Cdev_id_qp is > not getting used. >=20 > Not exactly. > cdev_id_qp is still setup, and is still used to decide to which crypto-de= v to > enqueuer the crypto-op: > ipsec_enqueue(...) > { > ... > enqueue_cop(&ipsec_ctx->tbl[sa->cdev_id_qp], &priv->cop); I don't see anybody filling "sa->cdev_id_qp". Please let me know if I have = missed it somewhere. It is memset to 0 I guess. >=20 >=20 > Same in ipsec_process(). >=20 > For initialization, yes cdev_id_qp is not used anymore. > As discussed here: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmails= .dp > dk.org%2Farchives%2Fdev%2F2019- > March%2F127725.html&data=3D02%7C01%7Cakhil.goyal%40nxp.com%7C04 > 194193cfc04c0b629008d6c7eea247%7C686ea1d3bc2b4c6fa92cd99c5c301635% > 7C0%7C0%7C636916225072561313&sdata=3Dga9IiqhYRWOz9QkRDIXNiigInk > soVGgu1E5EetqvE%2FA%3D&reserved=3D0 >=20 > I think the problem you are hitting with lookaside-proto is that for it > we use 2 different values here: > a) In create_sec_session we use portid (it also should be > rte_cryptodev_get_sec_ctx() here) > if (sa->type =3D=3D RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL) { > ctx =3D (struct rte_security_ctx *) > rte_eth_dev_get_sec_ctx(sa->portid); It should be rte_cryptodev_get_sec_ctx in the first place. And it needs a c= dev_id as input based on the cdev mapping done while initializing the crypt= odev and neither the portid and nor cdev_id_qp. > b) in enqueue() we use cdev_id_qp >=20 > Right now these values could be different. > As I understand we need to make sure that fro lookaside-proto cdev_id_qp = =3D=3D > portid provided by user, correct? No it is not the case. Right now for lookaside there is no use of portid in= case of lookaside case. As the cdev/qp/core mappings are managed internally and the user cannot twe= ak it from cfg file. >=20 >=20 > > The port_id cannot be used in case of crypto, the mapping of cdev/q= p/core > is done differently for inbound and outbound ports which is > > missed in this patch. > > > > 2. crypto sessions are created using the session mempool and the privat= e data > is allocated using the session priv_mempool which is > > removed in this patch. This will break cases where the priv data is mor= e than > the size of sess_mp element size. > > Also the security sessions need to be allocated using the session_p= riv_mp > instead of the session_mp. > > Please check this one. > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatche= s.d > pdk.org%2Fpatch%2F52981%2F&data=3D02%7C01%7Cakhil.goyal%40nxp.co > m%7C04194193cfc04c0b629008d6c7eea247%7C686ea1d3bc2b4c6fa92cd99c5c > 301635%7C0%7C0%7C636916225072561313&sdata=3DlibTy%2F%2Bj23gGru > vxhdlVUGIOeVq%2BlM2PIF1ZsgN%2FaSY%3D&reserved=3D0 >=20 > Yes, I think you right, we need to use sess_private_pool here. >=20 > > > > Ideally this issue should be resolved by adding another parameter in > rte_security_session_create which can take another mempool pointer > > for private data allocation. But this cannot be done in this release as= it would > need a deprecation notice. > > > > With the above issues I don't see your patch going in 19.05 release cyc= le. > > > > Regards, > > Akhil > > > > > > > > > > > > > > > > > > > - sec_cap =3D rte_security_capabilities_get(c= tx); > > > > + /* Set IPsec parameters in conf */ > > > > + set_ipsec_conf(sa, &(sess_conf.ipsec)); > > > > > > > > - /* iterate until ESP tunnel*/ > > > > - while (sec_cap->action !=3D > > > > - RTE_SECURITY_ACTION_TYPE_NO= NE) { > > > > + sa->sec_session =3D rte_security_session_create(ctx= , > > > > + &sess_conf, pool); > > > > + if (sa->sec_session =3D=3D NULL) { > > > > + RTE_LOG(ERR, IPSEC, > > > > + "SEC Session init failed: err: %d\n= ", > > > > + ret); > > > > + return -1; > > > > + }