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 0B9ECA034F; Fri, 8 Oct 2021 12:25:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E88CF40E3C; Fri, 8 Oct 2021 12:25:05 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id AF27140E25 for ; Fri, 8 Oct 2021 12:25:03 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10130"; a="225254829" X-IronPort-AV: E=Sophos;i="5.85,357,1624345200"; d="scan'208,217";a="225254829" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2021 03:25:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,357,1624345200"; d="scan'208,217";a="624691599" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmsmga001.fm.intel.com with ESMTP; 08 Oct 2021 03:25:00 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Fri, 8 Oct 2021 03:25:00 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx612.amr.corp.intel.com (10.22.229.25) 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, 8 Oct 2021 03:25:00 -0700 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (104.47.51.40) 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, 8 Oct 2021 03:24:59 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gH6ius9dP6FTLyQ4K+0KDtDNS/pUmDzwzD0FIrJZdSQM3eDrkC1pl738fvr/5iFyWgHvten5R77S7zcGPKwZ40vLl9JNOTQq0P1mSSYjlBiteztfRF9Qb2Z0X2x+dBocM+1I5d2NouGwhBT6dbLK8PhbVPQPYM1944xG6dxSL/YIPAV8ESe21DnoiCPc5t/O+EdMYiKiSJeqfwPMp92M2U6iAKBZHDYlrw+2HtiihbElr6XIBIYrT3v+0XuBOscrJVl5Ioms3cvIzO03czwPSqM4zLyuN6+fhkkXcQ+khVOaVTLsI+C8Lv3y9vLEYxqril/vutmQFYwDCjyaj+BJXQ== 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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2lzVNMsAsl0QJCSkH1JqGGQcJAlBvC1HxqU/5pqZWmQ=; b=jftGOwTmqjfYLNE6ZaJbHlRnLAEf1NBUxvs/CDR+FzRs2i5LdsVHwrs/0pzg9xt/tlbTVrqI8Mk71SwcVG9U2c39dMx8CvzkdeUZLtCjknZeOyMfO7MlhUiamP+P6X9vgXasMcYP4jmVlHW5tQhiEBj1IuK5UvD46S8DxJ0/5n31w6d9UPbQgPekktyMCf9EKl5vGPAS5PckijTn7KNhMC7CzJxUoXEQYfHOt+Zx9jzcj9HgcIsLayMRd10xa4f5JXzdTmbtLEkDEl3fTMp1M/+9SMPKgq7/undZ++ZpFjTFDLk10mtOZitk53lRxxNsqNdhRHvMhyJJ5b5wRD3agA== 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=2lzVNMsAsl0QJCSkH1JqGGQcJAlBvC1HxqU/5pqZWmQ=; b=fo2cGTMO+Oe0CtTBR8rDU28OFGlswuTKt3S2QrLl/X12/hYk4PJaelAWWDhBLVJk7OwgPaJNWGY3Jgz4Sv+hIA8JnZ7SvP4OpFC8df9hzCpFYtjKcfoEBP5YIhL9UK5ZAT2xlj1Uk8D6hM3YLwa9kL08320PrqSPgESkEdy7de8= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM6PR11MB2732.namprd11.prod.outlook.com (2603:10b6:5:be::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.22; Fri, 8 Oct 2021 10:24:52 +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.4587.019; Fri, 8 Oct 2021 10:24:52 +0000 From: "Ananyev, Konstantin" To: =?iso-2022-jp?B?GyRCaHE3RUQ2GyhC?= CC: "caihc1@chinatelecom.cn" , "dev@dpdk.org" Thread-Topic: Re:RE: Re:RE: [PATCH] ip_frag: modify the fragment offset and mf Thread-Index: AQHXs4dktefX2R5M1ky7XKVs8OracKvH1fAwgAD5ioCAAAIc4IAAF6wAgAALjoA= Date: Fri, 8 Oct 2021 10:24:52 +0000 Message-ID: References: <1632737174-86870-1-git-send-email-caihc1@chinatelecom.cn> <6d170a12.3a8e.17c5eef9a20.Coremail.chcchc88@163.com> <219b08da.4888.17c5f441607.Coremail.chcchc88@163.com> In-Reply-To: <219b08da.4888.17c5f441607.Coremail.chcchc88@163.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: 163.com; dkim=none (message not signed) header.d=none;163.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e3145975-030b-4311-ab67-08d98a45ddb2 x-ms-traffictypediagnostic: DM6PR11MB2732: 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: FvPJWbV1pbyDzs7tywg8ak/5w48/JrKD93/OXTtS/sgP0i/rzWSuPLZbUDthd+QFfIcBg1BOoyKWyVLimdouWHLdfX8saeAvi5XmOIX5Wl5Ny21PEvKnqHYBk3rL4Oa37UL1UGDMYnXokNJaa5Ppk+oUuu+QhYcXcR56cWpV+gQDe0Of4l1K/2fWevmclxAoutBRIuHnpK8Ju8LqeHJeFMzcBtfUpbmdMkaaXhv3Irk+LLDiUhD/3aaUJ+p/RS0BN3+5i2eGYwHHAm4bJaVKUlJZ+u8at0OncwOzeVJTE4sZ19kDYdwI9aZFLkfk4cahBTQJvQTFmiguGq7si4zE2tcpwivYNibNGtzXxe1jDGbYpxEZ4cI4rhhk9i48hID+oqZYM2uo8oo2IOqVPXjy/YZhUOTLxtqgfJ8g8U6clmT9K+WklBwQKjVzmFVDbiTOENG39GzR7Mtje2+EwT0BYcg3wIY11GgNbITjbnvsW3s0v3QSDEroeyU6YefZnS5kQMNVYdw+A9B+osfCEsLMlYyiOB2xJ51eN7i7AgT2+NHaMa8z3vzkzTJXRNrR1fKdM5Bp0jHiZBRWtRBsxzdL+V3d8m0VCr8zvmyWxkuGusQh4ebqotjLjZBIzm/L6GfYs1BJpSlEHXkQ2e+Nt+ceOTyempIVtX03QzhjUv2eib5ascD1xEtANlPYf6fzlJ7w0RUctRwHSK0jZ596J150noCBqjv40uZ0dZpVNMOFJqYjzjRmNjjhSTSeQfn/1heIADMr2FANg794IdAzpBoQjutc/DeCp0L0UZK8VmGR04GX/x5qW3ByamuKaPueD/iz 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)(33656002)(122000001)(64756008)(86362001)(38070700005)(38100700002)(83380400001)(9686003)(55016002)(66446008)(53546011)(2906002)(316002)(4326008)(54906003)(6506007)(26005)(5660300002)(52536014)(508600001)(186003)(55236004)(71200400001)(8676002)(966005)(6916009)(66556008)(66476007)(66946007)(166002)(7696005)(76116006)(8936002)(396324004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?OU5Ua2daTWVIT3VrUlZ0Wk1NQlEzZS9XdUpJalpVZzNHSS9yallpYjRB?= =?iso-2022-jp?B?WGV1cEN3UmFoZUVwcUk3WUhBV293bEhJYzB4S3YybE5sU0JZYXlJdkFz?= =?iso-2022-jp?B?TS9xdzhMWk54aGpJajFOd2c0MXY3MFZ1V0VuSCtFcm5SRXo4Q0tVaFV1?= =?iso-2022-jp?B?MHJJTklCblp0a283Y2wrQmNKcTVVYk5ya0hlZmptL294RWtWTW1SY1lX?= =?iso-2022-jp?B?UG1vakE3dTRpV3dsdDZVVm1JRk9KREUzTXgxL1NvczkwNDlvaHZLS3NF?= =?iso-2022-jp?B?bytXdHdUT0JDSjhLKzhJTHVRYXVwaTdpTEZZeGozaWJYVmV5TkdBbVFP?= =?iso-2022-jp?B?Z2hRZ01Kdng2bGc4NzdKa2VqWmtwUUpRSUhBMlBJWGwwMEt2ZWtxRXlk?= =?iso-2022-jp?B?Tm03a0ZkUHdYbk93TkxzemY3dlY2WjA3R3BBbHRxa3FuWE5ibXBQc0dr?= =?iso-2022-jp?B?NlRXbGMwajdxbzgrUUltdDd0SnQ1WlVmN05CdUw2SjJtWnhsak9rMHlz?= =?iso-2022-jp?B?ZzdrV2l5eSt2REVlNHY3N2h6SXpMT2t4SVdMSFM3VHo1dDdPMjlzbklv?= =?iso-2022-jp?B?VEpweCtGSkt0blh6MVB6UitpajFhUDBiSXk1clgwMkQzWkNXREtNa0lv?= =?iso-2022-jp?B?WGU2bDJsM2VmZlF2WU5kUS9xd3RDVy9yYTdQNXg3ZzdFRWs4YzJCQ1pT?= =?iso-2022-jp?B?ZjlSYVA5NW1SaExRTnBLTVVEV3orQ3VIbE5EaHhOYmhjaTZxVHhua3I4?= =?iso-2022-jp?B?TXBaT2tJT2RFUUFYWkJWbnVuVlFNUVdjaCtQem8zeS9UYnU3emNMYWNa?= =?iso-2022-jp?B?RjNVSndiS1ljNnJ4Q1BacnNoR1lDNU9LcnRJY2tGOGpBUTZXWWFCWUR0?= =?iso-2022-jp?B?eU5SZFphazZiUmk3by9DSUk2K0N3ZDNzT2VUdlNtTUNCY1ZlMlJDMnNz?= =?iso-2022-jp?B?dUxhbWU0cHVKSGNFUnV2eHlxRWJMNitNRWFJTnFCNk5DaTJMZVJZWXNz?= =?iso-2022-jp?B?dkczK1Q0a3d3UXQyUGhvMUpXYUJJT0NRVnpUTjBBRGdCUVpCZ2dTVGs4?= =?iso-2022-jp?B?MjVLZnluUkZ1c1BlMktKclFmSDRxUXZqNEQraHhDM1NZaXBNK2dWK3k2?= =?iso-2022-jp?B?eE5lbEh2dWJRaklNUVNXdnJKVDk1TXhIYmx1RkZjbysyOUljMUpRdk4v?= =?iso-2022-jp?B?cFd4YTNuS1F4UWVDUjU3T1dtQzBHTWwxL282RExPSlcxTUhDYTVZQXhZ?= =?iso-2022-jp?B?TlV1bTNFZFNmYjUvNG5xQTB3a09LWWIrT0xmOW93aFFaWjR5cUVSb3lT?= =?iso-2022-jp?B?eS9XYm1CY01CQ09wazRLakozQTcvQ3BSdklmMHROUU5NUTZaWjg3TDhj?= =?iso-2022-jp?B?MjgzS2psZnRtNFBCeUZZL0pNVTIvdUtpVFEweFptbWhnNit5R3BKYURy?= =?iso-2022-jp?B?VS85bUthb1l5VldjK2ZpYW5MdVgxZXVCTFg2SjhFZU9aTVN6a29IV0Zq?= =?iso-2022-jp?B?T2U5bE9oc0YwSktVSGl5SHQ0OTg3OFhwaDNIVjNBNlB4YlBKRUpJMXQv?= =?iso-2022-jp?B?a3YraEFRMkN6bFlVN0tkZStJZkxDZGROWjBLY29aVWhIUWRrb2dsSjZQ?= =?iso-2022-jp?B?WlB3c0FlMTNRSUpycmxWczJPVll6anRIVmZBZXlpdzN2RWEvVWZXZ2V4?= =?iso-2022-jp?B?TC9FMXpIRW5ScGYwWFgzdG11cmtNZ1M2eU9QcWhBeWkwVVQwNGlsQThE?= =?iso-2022-jp?B?ZWxNck9kaCtMdUg1ZU9XbXhWeEtNNjc2UHRwYXVQYXNQaU5OYVNkTDln?= =?iso-2022-jp?B?b241QjB5Qi91QlBPR2xteEdWVlM1YXNqNkVZQ050RkRJRC9URHZMNGRR?= =?iso-2022-jp?B?U0hYYnhGVUVEZjZzSitPRVZCT0dwd2lEeVdtd1labmNNd1hZM2NQVTFJ?= x-ms-exchange-transport-forked: True 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: e3145975-030b-4311-ab67-08d98a45ddb2 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 10:24:52.5417 (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: g07+T8gXUBcQoXog8zaqkHFDJ3Itq6tZ1+bny5AW6qpBBTeOac0Bndd1OL/Ppt5vjpLyZYJIH1a/qBqp1Pffk7WW9Fd/8ZjTGKlei22Vu6I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2732 X-OriginatorOrg: intel.com Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH] ip_frag: modify the fragment offset and mf 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" From: =1B$Bhq7ED6=1B(B Sent: Friday, October 8, 2021 10:38 AM To: Ananyev, Konstantin Cc: caihc1@chinatelecom.cn; dev@dpdk.org Subject: Re:RE: Re:RE: [PATCH] ip_frag: modify the fragment offset and mf Hi Konstantin, Thank you for your reply, it's so useful=1B$B!*!*!*=1B(B But I have some questions. Would you mind answer my questions=1B$B!)=1B(B >Cc: mailto:stable@dpdk.org This should be written in the commiter message=1B$B!'=1B(BCc: stable@dpdk.o= rg=1B$B!$=1B(Bright? [KA] Yes When I send patch,what is the parameters of --subject-prefix?(Which branch(= es)?) --subject-prefix=3D'PATCH vX=1B$B!G=1B(B, where X is the number of current = revision (2, 3, =1B$B!D=1B(B) I don't need to send patches to dev@dpdk.org anymore= =1B$B!$=1B(Bright? No, you do. I usually do something like that: git send-email --to dev@dpdk.org -cc --thread --no-chain-reply-to --in-reply-to=3D"MSG ID of previous version = of the patch=1B$B!I=1B(B >Bugzilla ID Let me start with Bugzilla-related material, which will take some time and may be created later when other bugs are foun= d. Best regards. Kevin At 2021-10-08 16:33:49, "Ananyev, Konstantin" > wrote: >Hi Kevin, > >I thought about something like that >(feel free to update it if you feel I missed something): > >ip_frag: fix fragmenting IPv4 fragment > >Current implementation of rte_ipv4_fragment_packet() doesn=1B$B!G=1B(Bt ta= ke >into account offset and flag values of the given packet, but blindly assum= es >they are always zero (original packet is not fragmented). >According to RFC791, fragment and flag values for new fragment should >take into account values provided in the original IPv4 packet. > >Fixes: 4c38e5532a07 ("ip_frag: refactor IPv4 fragmentation into a proper l= ibrary") >Cc: mailto:stable@dpdk.org > >Signed-off-by: ... > >> I searched for the frag keyword and found no bugs related to this patch. >I think there is none, but you can create one if you'd like. >Then, in the commit body, straight before "Fixes: ..." line, don=1B$B!G=1B= (Bt forget to add: >Bugzilla ID: > >Hope that helps >Konstantin > >From: =1B$Bhq7ED6=1B(B > >Sent: Friday, October 8, 2021 9:06 AM >To: Ananyev, Konstantin > >Cc: caihc1@chinatelecom.cn; dev@dpdk.org >Subject: Re:RE: [PATCH] ip_frag: modify the fragment offset and mf > >Hi,Ananyev, Konstantin > >Thank you for your reply.I'm sorry for my poor English.This is the first t= ime I've submitted a patch to the DPDK, and some of the processes are not f= amiliar.I am happy to contribute to the DPDK. > >As described in your message=1B$B!'=1B(B > >>As I understand what that patch does - fixes the case when we have >>to fragment already fragmented ip datagram, correct? >--Yes=1B$B!$=1B(Byou are right. > >>Can I ask you to do few things: >>1. Reword commit message, it is really misleading right now. >--Ok, I'll modify the commit message.But I'd like to confirm with you in a= dvance how to describe it, because you understand what the patch means.I in= tend to use your explanation as commit information=1B$B!'!H=1B(BFix the cas= e when we have to fragment already fragmented ip datagram.=1B$B!I=1B(BIs th= at okay? > >> Also if is a fix, then you need to follow: >> https://doc.dpdk.org/guides/contributing/patches.html#patch-fix-relat= ed-issues >--https://scan.coverity.com/projects/dpdk-data-plane-development-kit >--I ran into a problem when I clicked the button =1B$B!H=1B(BView Defects= =1B$B!I=1B(B : >401: Unauthorized >Sorry, your credentials are not valid for this resource. > >--But now I don't know how to apply for permission, and I'm asking mailto:= support@synopsys.com for help.I don't think this patch should be in Coverit= y. > >--Bugzilla >--I searched for the frag keyword and found no bugs related to this patch. >>2. Add new test-case for it into app/test/test_ipfrag.c >--Okay, I'll try to add it. > >Best regards. >huichao cai(Kevin). > > > > > > > >At 2021-10-08 01:26:17, "Ananyev, Konstantin" wrote: >> >> >>> From: huichao cai >>> >>> According to RFC791,the fragment offset value should be >>> calculated based on the long datagram,the more fragments flag >>> for the last fragment carries the same value as the long datagram. >> >>Have to admit, that commit log is really cryptic. >>I couldn't figure out what it is about till I read the actual code. >>As I understand what that patch does - fixes the case when we have >>to fragment already fragmented ip datagram, correct? >>The code changes itself look ok to me. >>Can I ask you to do few things: >>1. Reword commit message, it is really misleading right now. >> Also if is a fix, then you need to follow: >> https://doc.dpdk.org/guides/contributing/patches.html#patch-fix-relat= ed-issues >>2. Add new test-case for it into app/test/test_ipfrag.c >> >>Thanks >> >>> >>> Signed-off-by: huichao cai >>> --- >>> lib/ip_frag/rte_ipv4_fragmentation.c | 9 ++++++--- >>> 1 file changed, 6 insertions(+), 3 deletions(-) >>> >>> diff --git a/lib/ip_frag/rte_ipv4_fragmentation.c b/lib/ip_frag/rte_ipv= 4_fragmentation.c >>> index 2e7739d..fead5a9 100644 >>> --- a/lib/ip_frag/rte_ipv4_fragmentation.c >>> +++ b/lib/ip_frag/rte_ipv4_fragmentation.c >>> @@ -75,7 +75,7 @@ static inline void __free_fragments(struct rte_mbuf *= mb[], uint32_t num) >>> uint32_t out_pkt_pos, in_seg_data_pos; >>> uint32_t more_in_segs; >>> uint16_t fragment_offset, flag_offset, frag_size, header_len; >>> - uint16_t frag_bytes_remaining; >>> + uint16_t frag_bytes_remaining, not_last_frag; >>> >>> /* >>> * Formal parameter checking. >>> @@ -116,7 +116,9 @@ static inline void __free_fragments(struct rte_mbuf= *mb[], uint32_t num) >>> in_seg =3D pkt_in; >>> in_seg_data_pos =3D header_len; >>> out_pkt_pos =3D 0; >>> - fragment_offset =3D 0; >>> + fragment_offset =3D (uint16_t)((flag_offset & >>> + RTE_IPV4_HDR_OFFSET_MASK) << RTE_IPV4_HDR_FO_SHIFT); >>> + not_last_frag =3D (uint16_t)(flag_offset & IPV4_HDR_MF_MASK); >>> >>> more_in_segs =3D 1; >>> while (likely(more_in_segs)) { >>> @@ -186,7 +188,8 @@ static inline void __free_fragments(struct rte_mbuf= *mb[], uint32_t num) >>> >>> __fill_ipv4hdr_frag(out_hdr, in_hdr, header_len, >>> (uint16_t)out_pkt->pkt_len, >>> - flag_offset, fragment_offset, more_in_segs); >>> + flag_offset, fragment_offset, >>> + not_last_frag || more_in_segs); >>> >>> fragment_offset =3D (uint16_t)(fragment_offset + >>> out_pkt->pkt_len - header_len); >>> -- >>> 1.8.3.1 > >