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 636E9A0C43; Thu, 23 Sep 2021 16:09:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DCF8241273; Thu, 23 Sep 2021 16:09:35 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 8518041263 for ; Thu, 23 Sep 2021 16:09:33 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10115"; a="223497075" X-IronPort-AV: E=Sophos;i="5.85,316,1624345200"; d="scan'208";a="223497075" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2021 07:09:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,316,1624345200"; d="scan'208";a="653670051" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga005.jf.intel.com with ESMTP; 23 Sep 2021 07:09:28 -0700 Received: from fmsmsx604.amr.corp.intel.com (10.18.126.84) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Thu, 23 Sep 2021 07:09:28 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Thu, 23 Sep 2021 07:09:28 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.176) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Thu, 23 Sep 2021 07:09:28 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IbbrYMhl9e9k3FlzRu3mLf/Yqb7X6K8GdjAATUSrTP9ux4vHkTZk2VkifNKFHaxW+mO8lFeT5rqGPpynVX60JuuDH23S3G5+buBJTSfMbWSLwDQUkg/E6Yf3/3VD6AwYqyMg2P56+slbpRzwvTyToTjdYHwk3F4Z+YF0900jeT4MGoV9Tvl0+IwLTmfAH1JzUWv5EzBsLoXCoHxtq2mRsfykZoZPhB+mQ0rWeLYMBvJUC4uEwCOI4n55A14ylUtshH9eYD5kRCkML7T6Nzzi14/U9LsDqVkHKAdhNda7vD9ravFf1JhqMDPUmyTACLwDpgeti6ZrbAWlZjt8ffSmzQ== 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=XD/edGBLF9JqGDkZd8OyyDW11ps6koxPxITbTee2i/I=; b=JNX2nfWWK0mlPPc1HcTHEeeyt0ZcAo8OYk7yaPlMBIlEumykX3Y5/WB5r9SvXgP7/Y6OXVn9DlIsmyfSBD4Lb6Jdgxjv/tkKnDF2eEn5b27pvJpG84h+sb+jstZL0+EJkOmN9QEbYIyW2uNKNt/dTzjwVsCaaQr8hUm2rn/pJNUa9T+FpOLde5UOm0aF4n7O8cFR44tjnUBgxlludep5VpEJjGDZrHXzNPZXGaXChEsDMKT8RVwFayIOvYkSXO4hA86Qw7UQuL4B/rH48fL7gip9k1TyUjqOQ/scpra67H0+CNbca/LNK1Ptpj6KlH3VVX45KaxUYnlJaqLBPXNLPg== 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=XD/edGBLF9JqGDkZd8OyyDW11ps6koxPxITbTee2i/I=; b=YuBZJFK3NI0uOwsukfY1d8xzMT2JErkT+kOaFub4o+cDZZPPk2MLnW/ifRE9GG64BBkaNY16zMuCz9VxL4wsIKQf8ygX7MuHE+NlBK1L3FsKX4HXhoZhGxysK18CAm8sKq9OfYbDnr/YgsyE+r43QLQtkRGfoDMjDpMHTUUGWiA= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM6PR11MB4235.namprd11.prod.outlook.com (2603:10b6:5:205::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.18; Thu, 23 Sep 2021 14:09:24 +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.015; Thu, 23 Sep 2021 14:09:24 +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 06/10] ipsec: add transmit segmentation offload support Thread-Index: AQHXq6YUQYpEJNTt00+wuXcsUFuulauxqlCA Date: Thu, 23 Sep 2021 14:09:23 +0000 Message-ID: References: <20210713133542.3550525-1-radu.nicolau@intel.com> <20210917091747.1528262-1-radu.nicolau@intel.com> <20210917091747.1528262-7-radu.nicolau@intel.com> In-Reply-To: <20210917091747.1528262-7-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: a77d0d5c-1d6c-4fb5-7e4a-08d97e9bbf26 x-ms-traffictypediagnostic: DM6PR11MB4235: 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:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kG2/YTQY1yNCSyYyohQg3OyKL5Udu/W1GbCXg2BpTrjC1/gXmrVYtzpRJipMXWiZSZp6ogI3BnVwNO2oo/1zbDp4TcMEcP7z4WG2cJXW/zpX8Lu9bsebX9pJzQi0lE/W/wEwHrtsVM45BrcQL4X07OvOKzVo9rqOGetOHpo7A0b/3bWXU7/EJO1X0fMn7qmP5rO14dyMXCmeaowLV2hIOWM2K63kFJcaHPm8McftIVhXTAarVfAIAcmmlT+wcH87gJXYPSRdI4ek6kxwnZJjO33X3hD1kkAS+a/gY9N2sWXCI7OZh3U7vhMj68NoaD986+6HlwG2LhZsFC4lR9es1C8qI4JsPPAuIKLrpoC/1ZjEzj0HAr+m7V7/Sux4veq8WlBZPw331HCbyrwLnJbZsyaSzL7WCyvYpSXNwMju2lc/eIlLdij7tW9vB90rz6MAY6NJpC+S8mNzxN2VDqmAxMGMCWxGUKR+vyilYtRmL0AqCESOlpOnh5V38lzJGDGIEN9Qf43+4hqzWyAnba0hgq89ACP0d6KF05u6p4QnQzedvBYgiEphUxHE7hbbjf/WgReAiwO4/GuSqAJL+YH65fcPKa/aHp3W9yEJBs5F7m/ABtoq1h2XvxenutsaKX+FsoM5MlntzIq1/RBfl5u2mqen7Yn1z0r8pG7r3aEssgs6lD5JtssRvCcMxEco5hguSMl1t7d8P/Z3dlnimPKCoQ== 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)(8676002)(86362001)(71200400001)(9686003)(52536014)(66556008)(55016002)(55236004)(26005)(76116006)(316002)(186003)(83380400001)(2906002)(7696005)(110136005)(122000001)(54906003)(6636002)(4326008)(8936002)(38100700002)(66946007)(33656002)(38070700005)(66446008)(5660300002)(6506007)(64756008)(508600001)(30864003)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Yskqf2Ol26/XMufdOh0LX5L2DGI0nrzxKdJv/FijrKdPQ8u2fmlOleuR6Rvn?= =?us-ascii?Q?OYMg8IVAmeziyxydWPnienZivrRQIxuTXCUnI562zWxoQ2uaDLGWLyLGmG5l?= =?us-ascii?Q?dLYbFX6iEPxG8Vg3OnWXQ2GK/ExFruhyc2DvCqLbpQLkcrrhDgzEwXcbAe3r?= =?us-ascii?Q?ddnO8d0LtNxsKIVUJcIaDS+cAmUf6dRXjtqQggbQpocEEOgwm3Ab0aRNtcV8?= =?us-ascii?Q?Xu/eXNoLh7HbjsC8jxYkYrp1yjjTfD3j3luTv4TloEmhv0B0jVTp8c/cadan?= =?us-ascii?Q?w/LX8bICjTXwDU/5ktooEoXIfv2UAaqzE8eTnX0gWOWGrLBQG6VA+PQeVbrG?= =?us-ascii?Q?5F+P6rzZTz/1B2DoGpsaVk0TaNIqXIRGmZIQ+hrPscWOUzHArTeq7PdGrpML?= =?us-ascii?Q?dBAmo71stuHyOluyf4Rz/SeaKlCdM55iDE5/IsAXXFx63vno+2CexvXGSe3P?= =?us-ascii?Q?4laoEYgsewZ/m8XPXQdIEJIeE0HekCc+qEJ+/x6OVO5BtGH/CK0f7+ub9Z1t?= =?us-ascii?Q?Um+DRN7fGLibiDu2Xhmpjwz98dCsuCRxMVl5xIwIubdhXD19ygu7CsyqmX5E?= =?us-ascii?Q?LEF4TAkAkry6FgUy++dXfOnD+J6FWwkcBYgQ+JKHDnZ1O7JijM59GGCjQ1OD?= =?us-ascii?Q?3/ZR7Kd4JADyLb+lxJNXwg1v+4k/MbGgQGb9Jjz4pujN+0AZohlAwZcY0HwJ?= =?us-ascii?Q?kA63EXnUcNEgdnc+AYMwUUsn+Ove/5qtfgR3qvLXl/DnipB9CN5oQhEe9NYQ?= =?us-ascii?Q?P1aIoU5Uz/PIub6Qz442N26sCVXuMp2GEJVeYHQ3Pc/aypiNjuyrWKTlPbk6?= =?us-ascii?Q?YfG4PxM/V7pZhJ2fudQVMKIe+qU1x9xfryvNDxQlzSTR/fgRs5F33HNvhRRO?= =?us-ascii?Q?EMHyFJSk5Bd2VsgQl/R8BkGYzraxL/CUWWAR1LCWG5lhVPFRXv5AtFLzB778?= =?us-ascii?Q?0r/LMbcpvEr5Ui7QatYsDfavNEZaXfqy03cHEFB5LoZrldpRYNRwh6k9Zjqf?= =?us-ascii?Q?aEovaM0wX0y18O0Wgt4kw3PeA/FInxyW84hIjCoRQVA6hQw4VkFweVH+PjOq?= =?us-ascii?Q?oO2hKgP4196LIAhB9edrPkJa3zGwzDVhE0UWdFJz20fGjl07Erkmanv94och?= =?us-ascii?Q?Fz3xRdw4Aq6cemgDBxoNzJL7mrZiwzEi8OsMq7NSZE7KjIGQtR/UH/2lZPLT?= =?us-ascii?Q?BfofwV1bRyZZCgKNZi2gI9u/STN2p9Lk7t9UuMZuJXgFmcoVNYeiedhzxVmf?= =?us-ascii?Q?Lyn6qjlNbaDVEoM+NPwb5Se7FIDEB8sswfqHBepg07SY3vM92mh3/8wyKxKk?= =?us-ascii?Q?MKv0gHiupP/BO2FmLtq9s4UB?= 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: a77d0d5c-1d6c-4fb5-7e4a-08d97e9bbf26 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2021 14:09:23.9698 (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: KDnpebn+KaNq9N6qsMZqVcZKmJB8S4PPWj87df3CKAHYt+bqmMHXyb2hUoMVsBe58B6TuA8R27wLlxacLmKHYIuIOG4hB4iplt0oJpC8Edk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4235 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v6 06/10] ipsec: add transmit segmentation offload 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" > Add support for transmit segmentation offload to inline crypto processing > mode. This offload is not supported by other offload modes, as at a > minimum it requires inline crypto for IPsec to be supported on the > network interface. >=20 > Signed-off-by: Declan Doherty > Signed-off-by: Radu Nicolau > Signed-off-by: Abhijit Sinha > Signed-off-by: Daniel Martin Buckley > Acked-by: Fan Zhang > --- > lib/ipsec/esp_inb.c | 4 +- > lib/ipsec/esp_outb.c | 115 +++++++++++++++++++++++++++++++++++-------- > lib/ipsec/iph.h | 10 +++- > lib/ipsec/sa.c | 6 +++ > lib/ipsec/sa.h | 4 ++ > 5 files changed, 114 insertions(+), 25 deletions(-) >=20 > diff --git a/lib/ipsec/esp_inb.c b/lib/ipsec/esp_inb.c > index d66c88f05d..a6ab8fbdd5 100644 > --- a/lib/ipsec/esp_inb.c > +++ b/lib/ipsec/esp_inb.c > @@ -668,8 +668,8 @@ trs_process(const struct rte_ipsec_sa *sa, struct rte= _mbuf *mb[], > /* modify packet's layout */ > np =3D trs_process_step2(mb[i], ml[i], hl[i], cofs, > to[i], tl, sqn + k); > - update_trs_l3hdr(sa, np + l2, mb[i]->pkt_len, > - l2, hl[i] - l2, espt[i].next_proto); > + update_trs_l34hdrs(sa, np + l2, mb[i]->pkt_len, > + l2, hl[i] - l2, espt[i].next_proto, 0); >=20 > /* update mbuf's metadata */ > trs_process_step3(mb[i]); > diff --git a/lib/ipsec/esp_outb.c b/lib/ipsec/esp_outb.c > index a3f77469c3..9fc7075796 100644 > --- a/lib/ipsec/esp_outb.c > +++ b/lib/ipsec/esp_outb.c > @@ -2,6 +2,8 @@ > * Copyright(c) 2018-2020 Intel Corporation > */ >=20 > +#include > + > #include > #include > #include > @@ -156,11 +158,20 @@ outb_tun_pkt_prepare(struct rte_ipsec_sa *sa, rte_b= e64_t sqc, >=20 > /* number of bytes to encrypt */ > clen =3D plen + sizeof(*espt); > - clen =3D RTE_ALIGN_CEIL(clen, sa->pad_align); > + > + /* We don't need to pad/ailgn packet when using TSO offload */ > + if (likely(!(mb->ol_flags & (PKT_TX_TCP_SEG | PKT_TX_UDP_SEG)))) > + clen =3D RTE_ALIGN_CEIL(clen, sa->pad_align); > + Here and everywhere: It doesn't look nice that we have to pollute generic functions with checking TSO specific flags all over the place. Can we probably have a specific prepare/process function for inline+tso cas= e? As we do have for cpu and inline cases right now. Or just update inline version? >=20 > /* pad length + esp tail */ > pdlen =3D clen - plen; > - tlen =3D pdlen + sa->icv_len + sqh_len; > + > + /* We don't append ICV length when using TSO offload */ > + if (likely(!(mb->ol_flags & (PKT_TX_TCP_SEG | PKT_TX_UDP_SEG)))) > + tlen =3D pdlen + sa->icv_len + sqh_len; > + else > + tlen =3D pdlen + sqh_len; >=20 > /* do append and prepend */ > ml =3D rte_pktmbuf_lastseg(mb); > @@ -337,6 +348,7 @@ outb_trs_pkt_prepare(struct rte_ipsec_sa *sa, rte_be6= 4_t sqc, > char *ph, *pt; > uint64_t *iv; > uint32_t l2len, l3len; > + uint8_t tso =3D mb->ol_flags & (PKT_TX_TCP_SEG | PKT_TX_UDP_SEG) ? 1 : = 0; >=20 > l2len =3D mb->l2_len; > l3len =3D mb->l3_len; > @@ -349,11 +361,19 @@ outb_trs_pkt_prepare(struct rte_ipsec_sa *sa, rte_b= e64_t sqc, >=20 > /* number of bytes to encrypt */ > clen =3D plen + sizeof(*espt); > - clen =3D RTE_ALIGN_CEIL(clen, sa->pad_align); > + > + /* We don't need to pad/ailgn packet when using TSO offload */ > + if (likely(!tso)) > + clen =3D RTE_ALIGN_CEIL(clen, sa->pad_align); >=20 > /* pad length + esp tail */ > pdlen =3D clen - plen; > - tlen =3D pdlen + sa->icv_len + sqh_len; > + > + /* We don't append ICV length when using TSO offload */ > + if (likely(!tso)) > + tlen =3D pdlen + sa->icv_len + sqh_len; > + else > + tlen =3D pdlen + sqh_len; >=20 > /* do append and insert */ > ml =3D rte_pktmbuf_lastseg(mb); > @@ -375,8 +395,8 @@ outb_trs_pkt_prepare(struct rte_ipsec_sa *sa, rte_be6= 4_t sqc, > insert_esph(ph, ph + hlen, uhlen); >=20 > /* update ip header fields */ > - np =3D update_trs_l3hdr(sa, ph + l2len, mb->pkt_len - sqh_len, l2len, > - l3len, IPPROTO_ESP); > + np =3D update_trs_l34hdrs(sa, ph + l2len, mb->pkt_len - sqh_len, l2len, > + l3len, IPPROTO_ESP, tso); >=20 > /* update spi, seqn and iv */ > esph =3D (struct rte_esp_hdr *)(ph + uhlen); > @@ -651,6 +671,33 @@ inline_outb_mbuf_prepare(const struct rte_ipsec_sess= ion *ss, > } > } >=20 > +/* check if packet will exceed MSS and segmentation is required */ > +static inline int > +esn_outb_nb_segments(const struct rte_ipsec_sa *sa, struct rte_mbuf *m) = { > + uint16_t segments =3D 1; > + uint16_t pkt_l3len =3D m->pkt_len - m->l2_len; > + > + /* Only support segmentation for UDP/TCP flows */ > + if (!(m->packet_type & (RTE_PTYPE_L4_UDP | RTE_PTYPE_L4_TCP))) > + return segments; > + > + if (sa->tso.enabled && pkt_l3len > sa->tso.mss) { > + segments =3D ceil((float)pkt_l3len / sa->tso.mss); Float calculations in the middle of data-path? Just to calculate roundup? Doesn't look good to me at all. > + > + if (m->packet_type & RTE_PTYPE_L4_TCP) { > + m->ol_flags |=3D (PKT_TX_TCP_SEG | PKT_TX_TCP_CKSUM); That's really strange - why ipsec library will set PKT_TX_TCP_SEG unconditi= onally? That should be responsibility of the upper layer, I think. In the lib we should only check was tso requested for that packet or not. Same for UDP. > + m->l4_len =3D sizeof(struct rte_tcp_hdr); Hmm, how do we know there are no TCP options present for that packet? Wouldn't it be better to expect user to provide proper l4_len for such pack= ets? > + } else { > + m->ol_flags |=3D (PKT_TX_UDP_SEG | PKT_TX_UDP_CKSUM); > + m->l4_len =3D sizeof(struct rte_udp_hdr); > + } > + > + m->tso_segsz =3D sa->tso.mss; > + } > + > + return segments; > +} > + > /* > * process group of ESP outbound tunnel packets destined for > * INLINE_CRYPTO type of device. > @@ -660,24 +707,29 @@ inline_outb_tun_pkt_process(const struct rte_ipsec_= session *ss, > struct rte_mbuf *mb[], uint16_t num) > { > int32_t rc; > - uint32_t i, k, n; > + uint32_t i, k, nb_sqn =3D 0, nb_sqn_alloc; > uint64_t sqn; > rte_be64_t sqc; > struct rte_ipsec_sa *sa; > union sym_op_data icv; > uint64_t iv[IPSEC_MAX_IV_QWORD]; > uint32_t dr[num]; > + uint16_t nb_segs[num]; >=20 > sa =3D ss->sa; >=20 > - n =3D num; > - sqn =3D esn_outb_update_sqn(sa, &n); > - if (n !=3D num) > + for (i =3D 0; i !=3D num; i++) { > + nb_segs[i] =3D esn_outb_nb_segments(sa, mb[i]); > + nb_sqn +=3D nb_segs[i]; > + } > + > + nb_sqn_alloc =3D nb_sqn; > + sqn =3D esn_outb_update_sqn(sa, &nb_sqn_alloc); > + if (nb_sqn_alloc !=3D nb_sqn) > rte_errno =3D EOVERFLOW; >=20 > k =3D 0; > - for (i =3D 0; i !=3D n; i++) { > - > + for (i =3D 0; i !=3D num; i++) { > sqc =3D rte_cpu_to_be_64(sqn + i); > gen_iv(iv, sqc); >=20 > @@ -691,11 +743,18 @@ inline_outb_tun_pkt_process(const struct rte_ipsec_= session *ss, > dr[i - k] =3D i; > rte_errno =3D -rc; > } > + > + /** > + * If packet is using tso, increment sqn by the number of > + * segments for packet > + */ > + if (mb[i]->ol_flags & (PKT_TX_TCP_SEG | PKT_TX_UDP_SEG)) > + sqn +=3D nb_segs[i] - 1; > } >=20 > /* copy not processed mbufs beyond good ones */ > - if (k !=3D n && k !=3D 0) > - move_bad_mbufs(mb, dr, n, n - k); > + if (k !=3D num && k !=3D 0) > + move_bad_mbufs(mb, dr, num, num - k); >=20 > inline_outb_mbuf_prepare(ss, mb, k); > return k; > @@ -710,23 +769,30 @@ inline_outb_trs_pkt_process(const struct rte_ipsec_= session *ss, > struct rte_mbuf *mb[], uint16_t num) > { > int32_t rc; > - uint32_t i, k, n; > + uint32_t i, k, nb_sqn, nb_sqn_alloc; > uint64_t sqn; > rte_be64_t sqc; > struct rte_ipsec_sa *sa; > union sym_op_data icv; > uint64_t iv[IPSEC_MAX_IV_QWORD]; > uint32_t dr[num]; > + uint16_t nb_segs[num]; >=20 > sa =3D ss->sa; >=20 > - n =3D num; > - sqn =3D esn_outb_update_sqn(sa, &n); > - if (n !=3D num) > + /* Calculate number of sequence numbers required */ > + for (i =3D 0, nb_sqn =3D 0; i !=3D num; i++) { > + nb_segs[i] =3D esn_outb_nb_segments(sa, mb[i]); > + nb_sqn +=3D nb_segs[i]; > + } > + > + nb_sqn_alloc =3D nb_sqn; > + sqn =3D esn_outb_update_sqn(sa, &nb_sqn_alloc); > + if (nb_sqn_alloc !=3D nb_sqn) > rte_errno =3D EOVERFLOW; >=20 > k =3D 0; > - for (i =3D 0; i !=3D n; i++) { > + for (i =3D 0; i !=3D num; i++) { >=20 > sqc =3D rte_cpu_to_be_64(sqn + i); > gen_iv(iv, sqc); > @@ -741,11 +807,18 @@ inline_outb_trs_pkt_process(const struct rte_ipsec_= session *ss, > dr[i - k] =3D i; > rte_errno =3D -rc; > } > + > + /** > + * If packet is using tso, increment sqn by the number of > + * segments for packet > + */ > + if (mb[i]->ol_flags & (PKT_TX_TCP_SEG | PKT_TX_UDP_SEG)) > + sqn +=3D nb_segs[i] - 1; > } >=20 > /* copy not processed mbufs beyond good ones */ > - if (k !=3D n && k !=3D 0) > - move_bad_mbufs(mb, dr, n, n - k); > + if (k !=3D num && k !=3D 0) > + move_bad_mbufs(mb, dr, num, num - k); >=20 > inline_outb_mbuf_prepare(ss, mb, k); > return k; > diff --git a/lib/ipsec/iph.h b/lib/ipsec/iph.h > index 861f16905a..2d223199ac 100644 > --- a/lib/ipsec/iph.h > +++ b/lib/ipsec/iph.h > @@ -6,6 +6,8 @@ > #define _IPH_H_ >=20 > #include > +#include > +#include >=20 > /** > * @file iph.h > @@ -39,8 +41,8 @@ insert_esph(char *np, char *op, uint32_t hlen) >=20 > /* update original ip header fields for transport case */ > static inline int > -update_trs_l3hdr(const struct rte_ipsec_sa *sa, void *p, uint32_t plen, > - uint32_t l2len, uint32_t l3len, uint8_t proto) > +update_trs_l34hdrs(const struct rte_ipsec_sa *sa, void *p, uint32_t plen= , > + uint32_t l2len, uint32_t l3len, uint8_t proto, uint8_t tso) Hmm... why to change name of the function? > { > int32_t rc; >=20 > @@ -51,6 +53,10 @@ update_trs_l3hdr(const struct rte_ipsec_sa *sa, void *= p, uint32_t plen, > v4h =3D p; > rc =3D v4h->next_proto_id; > v4h->next_proto_id =3D proto; > + if (tso) { > + v4h->hdr_checksum =3D 0; > + v4h->total_length =3D 0; total_len will be overwritten unconditionally at next line below. Another question - why it is necessary? Is it HW specific requirment or ... ? > + } > v4h->total_length =3D rte_cpu_to_be_16(plen - l2len); > /* IPv6 */ > } else { > diff --git a/lib/ipsec/sa.c b/lib/ipsec/sa.c > index 720e0f365b..2ecbbce0a4 100644 > --- a/lib/ipsec/sa.c > +++ b/lib/ipsec/sa.c > @@ -565,6 +565,12 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const str= uct rte_ipsec_sa_prm *prm, > sa->type =3D type; > sa->size =3D sz; >=20 > + > + if (prm->ipsec_xform.options.tso =3D=3D 1) { > + sa->tso.enabled =3D 1; > + sa->tso.mss =3D prm->ipsec_xform.mss; > + } > + > /* check for ESN flag */ > sa->sqn_mask =3D (prm->ipsec_xform.options.esn =3D=3D 0) ? > UINT32_MAX : UINT64_MAX; > diff --git a/lib/ipsec/sa.h b/lib/ipsec/sa.h > index 107ebd1519..5e237f3525 100644 > --- a/lib/ipsec/sa.h > +++ b/lib/ipsec/sa.h > @@ -113,6 +113,10 @@ struct rte_ipsec_sa { > uint8_t iv_len; > uint8_t pad_align; > uint8_t tos_mask; > + struct { > + uint8_t enabled:1; > + uint16_t mss; > + } tso; Wouldn't one field be enough? uint16_t tso_mss; And it it is zero, then tso is disabled.=20 In fact, do we need it at all? Wouldn't it be better to request user to fill mbuf->tso_segsz properly for = us? >=20 > /* template for tunnel header */ > uint8_t hdr[IPSEC_MAX_HDR_SIZE]; > -- > 2.25.1