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 838EBA0548; Fri, 24 Sep 2021 13:39:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 11FAA4126F; Fri, 24 Sep 2021 13:39:17 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 45FEC4122D for ; Fri, 24 Sep 2021 13:39:15 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10116"; a="287725440" X-IronPort-AV: E=Sophos;i="5.85,319,1624345200"; d="scan'208";a="287725440" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2021 04:39:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,319,1624345200"; d="scan'208";a="475969731" Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19]) by fmsmga007.fm.intel.com with ESMTP; 24 Sep 2021 04:39:13 -0700 Received: from orsmsx606.amr.corp.intel.com (10.22.229.19) by ORSMSX606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Fri, 24 Sep 2021 04:39:13 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Fri, 24 Sep 2021 04:39:13 -0700 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (104.47.73.45) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Fri, 24 Sep 2021 04:39:13 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ikXaf1X49G7F6FSZdj/p32XZg1mZH41mfaPPMAwMri+kkJRwryym8cKw6+7Kud3euxBZtgl6RaYcaFA5cOpoTghlJm+PIAVt/BIIf8JCxDIIqMbADmbSjqGJLky+7HbdehqxgY9nEpq5CqwlhVAxLdFBR3JkA75ztHmVBrFaSIffNBvyxqg9MP6m5DZ7c8yYkWHbDHzpE4B4MaJ+3KyeUppx3VdDBU/dikovYvbDfP2uRC+lWSd9oMeUGmZCtr4jZDqkBBwwzygnKKo9tx4PsOjT/kwQLt4LNxwMArco4zi84M7N8djCk+BBw2ouEepaMa9eMB0AkDejLRtQszrrSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FLElYV/C33a+eT/HiYhJOGs65y7oyCvPzFnHXmzO6jQ=; b=X9MTDnzyZEC+hNq24kcrQTx9epGFFQaK2zJTPrtd2Gor7SmET8mHtYS9Eq5HlGiSJJQ0hzBZh3ehV7CIicoQO8g/JXiSwc1el70y7KzNhoCFrDBEQNFXxQ02Fd37rJ5UwCLAPt0wvWo0TOTDKRg0yud3pNjGEhUZ6jBDDq6/yO5vGz7+FlBxUDRgm9thlndAXUqwaOCd7Bgj+qrMwWP/Ad5wpatheIsUMHEzcPnlSHPYewwALr6SnZB+z3yFEMXXKGAxN5nneNljGkqIosaCdHZTBklbwmwhD5G6sy62h2pP9c/5B8mjeF9N06iaTK4U3jfuzMTNSpGEp3dbtF+4/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FLElYV/C33a+eT/HiYhJOGs65y7oyCvPzFnHXmzO6jQ=; b=B+uFs5wNlOuqLrPQhzx5sYUjFxS2FIhn+WBrWleJYITdHYWbrkRGQWtGSC4/kSYewMe4FX1Wsrxm1/R4Pu+AUDeJPccW7sFxK05qUf7fa9+arHMBGIhs6hitH4H4mNwqEITgyzNQzXyMLxouuqr/YLxhFOIIeOb0d5mHzHsOhrw= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM5PR1101MB2251.namprd11.prod.outlook.com (2603:10b6:4:53::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.13; Fri, 24 Sep 2021 11:39:11 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::740e:126e:c785:c8fd]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::740e:126e:c785:c8fd%4]) with mapi id 15.20.4544.018; Fri, 24 Sep 2021 11:39:11 +0000 From: "Ananyev, Konstantin" To: "Nicolau, Radu" , "Iremonger, Bernard" , "Medvedkin, Vladimir" CC: "dev@dpdk.org" , "mdr@ashroe.eu" , "Richardson, Bruce" , "Zhang, Roy Fan" , "hemant.agrawal@nxp.com" , "gakhil@marvell.com" , "anoobj@marvell.com" , "Doherty, Declan" , "Sinha, Abhijit" , "Buckley, Daniel M" , "marchana@marvell.com" , "ktejasree@marvell.com" , "matan@nvidia.com" Thread-Topic: [PATCH v6 10/10] ipsec: add ol_flags support Thread-Index: AQHXq6YbFKFJ1pSHa0OheJ23tYRiK6uzBM0w Date: Fri, 24 Sep 2021 11:39:10 +0000 Message-ID: References: <20210713133542.3550525-1-radu.nicolau@intel.com> <20210917091747.1528262-1-radu.nicolau@intel.com> <20210917091747.1528262-11-radu.nicolau@intel.com> In-Reply-To: <20210917091747.1528262-11-radu.nicolau@intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c75cb255-8a93-48f1-b550-08d97f4fed4d x-ms-traffictypediagnostic: DM5PR1101MB2251: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T371QzoRjhIdcOallcUTc8awTwT7M1rxG+wKb5zUkqm5vcFvQvrkkimvnMj1kcwFRbViC217dJ2733gu/SR14mGVlwpalpRdn8uG79cqENvng64D6IJTT3WuHbCuL9Od5zm9iS61KxMZPV9QoBbbdnW2TUV991LwHSnAtDxDuKzwhBf8Us1CGPH6xUdv4j69eePG32KgUIkdUdTVJyqstO6srLR8BZ1SCH5kf/yzVc2zvFJThiu+0gtxjdvCbhqurHoDtaRbglD6AUTf2tqyWyNmleRF10LslNYbKnNmj7AiexvPV1NGsV8YLDA02Vv9Ht128DmepFkcwDEoVJLX1X71DmG7L6SVijXCysicYrhXwfcJcPxr6yjCy5HRqYJQpT5NU1KECgiupYo0F4Vf0YDZldlyWxLx+gcAltgJ8jLuSMi1VUNqusMP3r77Bbz0tyKqbkThm2BNAz4rLCNUy/bSxAaeO+Bq2AjCIuzdJN8RusxjiLb75X6MQj3+7eUye7MZLoBUChXKTVJ8QxO9xSk3DFxgW1BCsHGP4bl0YGGIAdLIkFvLmBz0R0nt0DaM/Ewhjm+SnAVRjJPFBMibva/B/VLrr4cYxtRKwnQHkmz80doe+0DEeXmqBJCYBLEJeqfMsDI88hrxPeBldwTGigGVFYIyjlwwwMrD2B94YWw0UKKPJU/FhRDFo8zHay0QGdNe8ZU8ksAenjjrvkFyHw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4491.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(316002)(8676002)(6506007)(8936002)(52536014)(38100700002)(66446008)(66556008)(71200400001)(64756008)(30864003)(508600001)(55236004)(110136005)(66946007)(54906003)(33656002)(38070700005)(6636002)(7696005)(186003)(5660300002)(122000001)(2906002)(9686003)(83380400001)(26005)(4326008)(66476007)(76116006)(86362001)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?EdyzrVFVdxQovzNzayOekS4CgZW6ehmvIJEBsk5VsbspvqihnVgl97BOu/zX?= =?us-ascii?Q?DJh3Dr1jqqRb9HaIIwz8211PIiI9quaHQSzChie4HK5xEp98/svYynedhIeR?= =?us-ascii?Q?f7XAKI5+oI7kPybC5/PqNqWNn+YAiLl/SRQHMXGfnDLLz7Ee+JtJD2tAL582?= =?us-ascii?Q?eqWnh00DJG7HBXvwsljumYIx9QQh7EnkCJIzvl9Y/t/z/cU36oEu7QMa4iqN?= =?us-ascii?Q?rE6mSmmlJ3XXgQeYd5xtz/ml16WmxpyYKQEwNTeXnQ4NJxi/YMXShwLvwF43?= =?us-ascii?Q?eRasN7hFcZe+O9DINuL+CQtCb6OP+r6ZPqpvN3Aq7q2fuZCCAD6Rxc1/3+AP?= =?us-ascii?Q?SOxHiKfyLavQlMs3I0H1B67cd4yLH5oaWawugyxWKcSSs4QVzSww+6o3iRSF?= =?us-ascii?Q?6m9NkzKqVw+Y5uA6kctJBtsIAstMOD7ZvwNx3RskYTREdTZtu2U2c8m3rywe?= =?us-ascii?Q?uwqBxGTwHGmMYXOAvJrAAPa10khDWNaggKWf7gc8C4olghHjyLxcLUrEddVh?= =?us-ascii?Q?T1rC//pj4EV886U6puRBxZhCl/OV4GoK662EKl+dXsvytvTEDSxT8pzKg+3a?= =?us-ascii?Q?0wLx+kuAgu/ZJxoEEqsOm13hl6uZ9WtjJBKj8ML9+VHR00W3hTSymDMRTkP1?= =?us-ascii?Q?lfhymuPMNRaAoLvbEubjtTx+kM6OTJ/+YgEq5lsjfvazoEEqIzlBdVann0vP?= =?us-ascii?Q?/dYM7bgqt9XBWF3F/0NlDpcq3HkU4vKfZ6eX6FAq1z1mQikv/7Jd/jJL4E7a?= =?us-ascii?Q?l8TlYjOMlryLgHBZ7c84ogrhs4zaBTOgS7LBMbmjpHYYVn63vA2CG51jak4q?= =?us-ascii?Q?QLxLoU2m4FDlHezp+YfoNrhjSpP8GsP+YBLqeuDBmn7qydRuShVXsQjYEhfW?= =?us-ascii?Q?vZR3p2cVjrMN2gojBmclnsKlkGBmeKd5rqt6JGj9u4nXqWri0DkI54/NS4Ny?= =?us-ascii?Q?crdsoXyK8fZetd0V9ien+6oJT2PAtGz01gUzA2fpWOF+vJBI4b304+Xxb6nd?= =?us-ascii?Q?SXVyJ+PZ8c4VNrMO+vIDvZ3AY+pPvvKn4HBiZi4IWa/mOZsn87fZx/qpwU0R?= =?us-ascii?Q?AVa+nqSwS/7uSQt3vqTj7Y8fa1OLkyF6Ami4BtP5E+B3ACkwbYanLf5LCqsH?= =?us-ascii?Q?GwyAHrAJdCVVri5XNg49C2YbgipTz310ud/PeQC4c7TOAmWijGEpDebt2li1?= =?us-ascii?Q?sqyw/9g9svBFYG1z6hXPldLoYgV7zmou+DDPhrSE3FAtc/uBo6WadIqOMz74?= =?us-ascii?Q?/96+XvVuT9EuOiE7hgcbcVYmxDDAoaUGbTaT8hxGI75a+qLiXXhxB7UmX72o?= =?us-ascii?Q?soWN8ouoxgrrp0RVInpEIZuK?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4491.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c75cb255-8a93-48f1-b550-08d97f4fed4d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2021 11:39:10.7654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LZQveA/c3yQvskG3zW4Mf+tXyoAJI4sQlunHCQNjxzuAQ6OyEM2If0wHiAaSGjNolYooabzkVTTpVu/PxvZwSbEib03Iskxn2O6+7RqsYgA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2251 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v6 10/10] ipsec: add ol_flags support 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 Sender: "dev" > Update the IPsec library to set mbuff->ol_flags and use the configured > L3 header length when setting the mbuff->tx_offload fields You stated what pactch does, but didn't explain why it is needed. >=20 > Signed-off-by: Declan Doherty > Signed-off-by: Radu Nicolau > Signed-off-by: Abhijit Sinha > Signed-off-by: Daniel Martin Buckley > --- > lib/ipsec/esp_inb.c | 17 ++++++++++++-- > lib/ipsec/esp_outb.c | 48 ++++++++++++++++++++++++++++++--------- > lib/ipsec/rte_ipsec_sa.h | 3 ++- > lib/ipsec/sa.c | 49 ++++++++++++++++++++++++++++++++++++++-- > lib/ipsec/sa.h | 8 +++++++ > 5 files changed, 109 insertions(+), 16 deletions(-) >=20 > diff --git a/lib/ipsec/esp_inb.c b/lib/ipsec/esp_inb.c > index 8cb4c16302..5fcb41297e 100644 > --- a/lib/ipsec/esp_inb.c > +++ b/lib/ipsec/esp_inb.c > @@ -559,7 +559,8 @@ trs_process_step3(struct rte_mbuf *mb) > * - tx_offload > */ > static inline void > -tun_process_step3(struct rte_mbuf *mb, uint64_t txof_msk, uint64_t txof_= val) > +tun_process_step3(struct rte_mbuf *mb, uint8_t is_ipv4, uint64_t txof_ms= k, > + uint64_t txof_val) > { > /* reset mbuf metatdata: L2/L3 len, packet type */ > mb->packet_type =3D RTE_PTYPE_UNKNOWN; > @@ -567,6 +568,14 @@ tun_process_step3(struct rte_mbuf *mb, uint64_t txof= _msk, uint64_t txof_val) >=20 > /* clear the PKT_RX_SEC_OFFLOAD flag if set */ > mb->ol_flags &=3D ~PKT_RX_SEC_OFFLOAD; > + > + if (is_ipv4) { > + mb->l3_len =3D sizeof(struct rte_ipv4_hdr); > + mb->ol_flags |=3D (PKT_TX_IPV4 | PKT_TX_IP_CKSUM); > + } else { > + mb->l3_len =3D sizeof(struct rte_ipv6_hdr); > + mb->ol_flags |=3D PKT_TX_IPV6; > + } That's TX related flags. Why do you set them for inbound traffic? > } >=20 > /* > @@ -618,8 +627,12 @@ tun_process(const struct rte_ipsec_sa *sa, struct rt= e_mbuf *mb[], > update_tun_inb_l3hdr(sa, outh, inh); >=20 > /* update mbuf's metadata */ > - tun_process_step3(mb[i], sa->tx_offload.msk, > + tun_process_step3(mb[i], > + (sa->type & RTE_IPSEC_SATP_IPV_MASK) =3D=3D > + RTE_IPSEC_SATP_IPV4 ? 1 : 0, > + sa->tx_offload.msk, > sa->tx_offload.val); > + > k++; > } else > dr[i - k] =3D i; > diff --git a/lib/ipsec/esp_outb.c b/lib/ipsec/esp_outb.c > index 8a6d09558f..d8e261e6fb 100644 > --- a/lib/ipsec/esp_outb.c > +++ b/lib/ipsec/esp_outb.c > @@ -19,7 +19,7 @@ >=20 > typedef int32_t (*esp_outb_prepare_t)(struct rte_ipsec_sa *sa, rte_be64_= t sqc, > const uint64_t ivp[IPSEC_MAX_IV_QWORD], struct rte_mbuf *mb, > - union sym_op_data *icv, uint8_t sqh_len); > + union sym_op_data *icv, uint8_t sqh_len, uint8_t icrypto); Sigh, what does icrypto mean and why it is needed? It really would help if you bother to put at least some comments explaining= your changes. If that's for inline crypto specific add-ons then why it has to be there, i= n generic function? Why not in inline_outb_tun_pkt_process()? >=20 > /* > * helper function to fill crypto_sym op for cipher+auth algorithms. > @@ -140,9 +140,9 @@ outb_cop_prepare(struct rte_crypto_op *cop, > static inline int32_t > outb_tun_pkt_prepare(struct rte_ipsec_sa *sa, rte_be64_t sqc, > const uint64_t ivp[IPSEC_MAX_IV_QWORD], struct rte_mbuf *mb, > - union sym_op_data *icv, uint8_t sqh_len) > + union sym_op_data *icv, uint8_t sqh_len, uint8_t icrypto) > { > - uint32_t clen, hlen, l2len, pdlen, pdofs, plen, tlen; > + uint32_t clen, hlen, l2len, l3len, pdlen, pdofs, plen, tlen; > struct rte_mbuf *ml; > struct rte_esp_hdr *esph; > struct rte_esp_tail *espt; > @@ -154,6 +154,8 @@ outb_tun_pkt_prepare(struct rte_ipsec_sa *sa, rte_be6= 4_t sqc, >=20 > /* size of ipsec protected data */ > l2len =3D mb->l2_len; > + l3len =3D mb->l3_len; > + > plen =3D mb->pkt_len - l2len; >=20 > /* number of bytes to encrypt */ > @@ -190,8 +192,26 @@ outb_tun_pkt_prepare(struct rte_ipsec_sa *sa, rte_be= 64_t sqc, > pt =3D rte_pktmbuf_mtod_offset(ml, typeof(pt), pdofs); >=20 > /* update pkt l2/l3 len */ > - mb->tx_offload =3D (mb->tx_offload & sa->tx_offload.msk) | > - sa->tx_offload.val; > + if (icrypto) { > + mb->tx_offload =3D > + (mb->tx_offload & sa->inline_crypto.tx_offload.msk) | > + sa->inline_crypto.tx_offload.val; > + mb->l3_len =3D l3len; > + > + mb->ol_flags |=3D sa->inline_crypto.tx_ol_flags; > + > + /* set ip checksum offload for inner */ > + if ((sa->type & RTE_IPSEC_SATP_IPV_MASK) =3D=3D RTE_IPSEC_SATP_IPV4) > + mb->ol_flags |=3D (PKT_TX_IPV4 | PKT_TX_IP_CKSUM); > + else if ((sa->type & RTE_IPSEC_SATP_IPV_MASK) > + =3D=3D RTE_IPSEC_SATP_IPV6) > + mb->ol_flags |=3D PKT_TX_IPV6; > + } else { > + mb->tx_offload =3D (mb->tx_offload & sa->tx_offload.msk) | > + sa->tx_offload.val; > + > + mb->ol_flags |=3D sa->tx_ol_flags; > + } >=20 > /* copy tunnel pkt header */ > rte_memcpy(ph, sa->hdr, sa->hdr_len); > @@ -311,7 +331,7 @@ esp_outb_tun_prepare(const struct rte_ipsec_session *= ss, struct rte_mbuf *mb[], >=20 > /* try to update the packet itself */ > rc =3D outb_tun_pkt_prepare(sa, sqc, iv, mb[i], &icv, > - sa->sqh_len); > + sa->sqh_len, 0); > /* success, setup crypto op */ > if (rc >=3D 0) { > outb_pkt_xprepare(sa, sqc, &icv); > @@ -338,7 +358,7 @@ esp_outb_tun_prepare(const struct rte_ipsec_session *= ss, struct rte_mbuf *mb[], > static inline int32_t > outb_trs_pkt_prepare(struct rte_ipsec_sa *sa, rte_be64_t sqc, > const uint64_t ivp[IPSEC_MAX_IV_QWORD], struct rte_mbuf *mb, > - union sym_op_data *icv, uint8_t sqh_len) > + union sym_op_data *icv, uint8_t sqh_len, uint8_t icrypto __rte_unused) > { > uint8_t np; > uint32_t clen, hlen, pdlen, pdofs, plen, tlen, uhlen; > @@ -394,10 +414,16 @@ outb_trs_pkt_prepare(struct rte_ipsec_sa *sa, rte_b= e64_t sqc, > /* shift L2/L3 headers */ > insert_esph(ph, ph + hlen, uhlen); >=20 > + if ((sa->type & RTE_IPSEC_SATP_IPV_MASK) =3D=3D RTE_IPSEC_SATP_IPV4) > + mb->ol_flags |=3D (PKT_TX_IPV4 | PKT_TX_IP_CKSUM); > + else if ((sa->type & RTE_IPSEC_SATP_IPV_MASK) =3D=3D RTE_IPSEC_SATP_IPV= 6) > + mb->ol_flags |=3D PKT_TX_IPV6; Why do ipsec lib now have to setup these flags unconditionally? If that's a change in functionality - it should be documented properly with clear explanation why. If you believe it is a bug in current ipsec implementation - then it should= be separate 'fix' patch.=20 But so far, I don't see any good reason for that. > /* update ip header fields */ > np =3D update_trs_l34hdrs(sa, ph + l2len, mb->pkt_len - sqh_len, l2len, > l3len, IPPROTO_ESP, tso); >=20 > + Empty line. > /* update spi, seqn and iv */ > esph =3D (struct rte_esp_hdr *)(ph + uhlen); > iv =3D (uint64_t *)(esph + 1); > @@ -463,7 +489,7 @@ esp_outb_trs_prepare(const struct rte_ipsec_session *= ss, struct rte_mbuf *mb[], >=20 > /* try to update the packet itself */ > rc =3D outb_trs_pkt_prepare(sa, sqc, iv, mb[i], &icv, > - sa->sqh_len); > + sa->sqh_len, 0); > /* success, setup crypto op */ > if (rc >=3D 0) { > outb_pkt_xprepare(sa, sqc, &icv); > @@ -560,7 +586,7 @@ cpu_outb_pkt_prepare(const struct rte_ipsec_session *= ss, > gen_iv(ivbuf[k], sqc); >=20 > /* try to update the packet itself */ > - rc =3D prepare(sa, sqc, ivbuf[k], mb[i], &icv, sa->sqh_len); > + rc =3D prepare(sa, sqc, ivbuf[k], mb[i], &icv, sa->sqh_len, 0); >=20 > /* success, proceed with preparations */ > if (rc >=3D 0) { > @@ -741,7 +767,7 @@ inline_outb_tun_pkt_process(const struct rte_ipsec_se= ssion *ss, > gen_iv(iv, sqc); >=20 > /* try to update the packet itself */ > - rc =3D outb_tun_pkt_prepare(sa, sqc, iv, mb[i], &icv, 0); > + rc =3D outb_tun_pkt_prepare(sa, sqc, iv, mb[i], &icv, 0, 1); >=20 > k +=3D (rc >=3D 0); >=20 > @@ -808,7 +834,7 @@ inline_outb_trs_pkt_process(const struct rte_ipsec_se= ssion *ss, > gen_iv(iv, sqc); >=20 > /* try to update the packet itself */ > - rc =3D outb_trs_pkt_prepare(sa, sqc, iv, mb[i], &icv, 0); > + rc =3D outb_trs_pkt_prepare(sa, sqc, iv, mb[i], &icv, 0, 0); >=20 > k +=3D (rc >=3D 0); >=20 > diff --git a/lib/ipsec/rte_ipsec_sa.h b/lib/ipsec/rte_ipsec_sa.h > index 40d1e70d45..3c36dcaa77 100644 > --- a/lib/ipsec/rte_ipsec_sa.h > +++ b/lib/ipsec/rte_ipsec_sa.h > @@ -38,7 +38,8 @@ struct rte_ipsec_sa_prm { > union { > struct { > uint8_t hdr_len; /**< tunnel header len */ > - uint8_t hdr_l3_off; /**< offset for IPv4/IPv6 header */ > + uint8_t hdr_l3_off; /**< tunnel l3 header len */ > + uint8_t hdr_l3_len; /**< tunnel l3 header len */ > uint8_t next_proto; /**< next header protocol */ > const void *hdr; /**< tunnel header template */ > } tun; /**< tunnel mode related parameters */ > diff --git a/lib/ipsec/sa.c b/lib/ipsec/sa.c > index d94684cf96..149ed5dd4f 100644 > --- a/lib/ipsec/sa.c > +++ b/lib/ipsec/sa.c > @@ -17,6 +17,8 @@ >=20 > #define MBUF_MAX_L2_LEN RTE_LEN2MASK(RTE_MBUF_L2_LEN_BITS, uint64_t) > #define MBUF_MAX_L3_LEN RTE_LEN2MASK(RTE_MBUF_L3_LEN_BITS, uint64_t) > +#define MBUF_MAX_TSO_LEN RTE_LEN2MASK(RTE_MBUF_TSO_SEGSZ_BITS, uint64_t) > +#define MBUF_MAX_OL3_LEN RTE_LEN2MASK(RTE_MBUF_OUTL3_LEN_BITS, uint64_t) >=20 > /* some helper structures */ > struct crypto_xform { > @@ -348,6 +350,11 @@ esp_outb_init(struct rte_ipsec_sa *sa, uint32_t hlen= , uint64_t sqn) > sa->cofs.ofs.cipher.head =3D sa->ctp.cipher.offset - sa->ctp.auth.offse= t; > sa->cofs.ofs.cipher.tail =3D (sa->ctp.auth.offset + sa->ctp.auth.length= ) - > (sa->ctp.cipher.offset + sa->ctp.cipher.length); > + > + if (sa->type & RTE_IPSEC_SATP_MODE_TUNLV4) > + sa->tx_ol_flags |=3D (PKT_TX_IPV4 | PKT_TX_IP_CKSUM); > + else if (sa->type & RTE_IPSEC_SATP_MODE_TUNLV6) > + sa->tx_ol_flags |=3D PKT_TX_IPV6; Same question: why these flags have to be *always* and unconditionally set? This is a change in behaviour and there should be a really good reason for = that. And if we will decide to proceed with it - it should be clearly outlined in= both doc and commit message. > } >=20 > /* > @@ -362,9 +369,43 @@ esp_outb_tun_init(struct rte_ipsec_sa *sa, const str= uct rte_ipsec_sa_prm *prm) > sa->hdr_len =3D prm->tun.hdr_len; > sa->hdr_l3_off =3D prm->tun.hdr_l3_off; >=20 > + > + /* update l2_len and l3_len fields for outbound mbuf */ > + sa->inline_crypto.tx_offload.val =3D rte_mbuf_tx_offload( > + 0, /* iL2_LEN */ > + 0, /* iL3_LEN */ > + 0, /* iL4_LEN */ > + 0, /* TSO_SEG_SZ */ > + prm->tun.hdr_l3_len, /* oL3_LEN */ > + prm->tun.hdr_l3_off, /* oL2_LEN */ > + 0); > + sa->inline_crypto.tx_ol_flags |=3D PKT_TX_TUNNEL_ESP; > + > + if (sa->type & RTE_IPSEC_SATP_MODE_TUNLV4) > + sa->inline_crypto.tx_ol_flags |=3D PKT_TX_OUTER_IPV4; > + else if (sa->type & RTE_IPSEC_SATP_MODE_TUNLV6) > + sa->inline_crypto.tx_ol_flags |=3D PKT_TX_OUTER_IPV6; > + > + if (sa->inline_crypto.tx_ol_flags & PKT_TX_OUTER_IPV4) > + sa->inline_crypto.tx_ol_flags |=3D PKT_TX_OUTER_IP_CKSUM; > + if (sa->tx_ol_flags & PKT_TX_IPV4) > + sa->inline_crypto.tx_ol_flags |=3D PKT_TX_IP_CKSUM; > + > /* update l2_len and l3_len fields for outbound mbuf */ > - sa->tx_offload.val =3D rte_mbuf_tx_offload(sa->hdr_l3_off, > - sa->hdr_len - sa->hdr_l3_off, 0, 0, 0, 0, 0); > + sa->tx_offload.val =3D rte_mbuf_tx_offload( > + prm->tun.hdr_l3_off, /* iL2_LEN */ > + prm->tun.hdr_l3_len, /* iL3_LEN */ Sigh, again that's the change in current behaviour. What would happen for old apps that doesn't set hdr_l3_len properly? > + 0, /* iL4_LEN */ > + 0, /* TSO_SEG_SZ */ > + 0, /* oL3_LEN */ > + 0, /* oL2_LEN */ > + 0); > + > + if (sa->type & RTE_IPSEC_SATP_MODE_TUNLV4) > + sa->tx_ol_flags |=3D (PKT_TX_IPV4 | PKT_TX_IP_CKSUM); > + else if (sa->type & RTE_IPSEC_SATP_MODE_TUNLV6) > + sa->tx_ol_flags |=3D PKT_TX_IPV6; >=20 > memcpy(sa->hdr, prm->tun.hdr, sa->hdr_len); >=20 > @@ -473,6 +514,10 @@ esp_sa_init(struct rte_ipsec_sa *sa, const struct rt= e_ipsec_sa_prm *prm, > sa->salt =3D prm->ipsec_xform.salt; >=20 > /* preserve all values except l2_len and l3_len */ > + sa->inline_crypto.tx_offload.msk =3D > + ~rte_mbuf_tx_offload(MBUF_MAX_L2_LEN, MBUF_MAX_L3_LEN, > + 0, 0, MBUF_MAX_OL3_LEN, 0, 0); > + > sa->tx_offload.msk =3D > ~rte_mbuf_tx_offload(MBUF_MAX_L2_LEN, MBUF_MAX_L3_LEN, > 0, 0, 0, 0, 0); > diff --git a/lib/ipsec/sa.h b/lib/ipsec/sa.h > index b9b7ebec5b..172d094c4b 100644 > --- a/lib/ipsec/sa.h > +++ b/lib/ipsec/sa.h > @@ -101,6 +101,14 @@ struct rte_ipsec_sa { > uint64_t msk; > uint64_t val; > } tx_offload; > + uint64_t tx_ol_flags; > + struct { > + uint64_t tx_ol_flags; > + struct { > + uint64_t msk; > + uint64_t val; > + } tx_offload; > + } inline_crypto; I don't see any reason why we need two tx_offload fields (and tx_ol_flags) = - one generic, second for inline. I believe both can be squeezed into just one value. For different methods (inline/lookaside) these values will be just differen= t. Probably these fields need to be moved from struct rte_ipsec_sa, to rte_ips= ec_session. > struct { > uint16_t sport; > uint16_t dport; > -- > 2.25.1