From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 22D46A09EE for ; Sat, 12 Dec 2020 10:53:47 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DAD0CBC84; Sat, 12 Dec 2020 10:53:45 +0100 (CET) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by dpdk.org (Postfix) with ESMTP id 39958A54E; Sat, 12 Dec 2020 10:53:40 +0100 (CET) Received: from DGGEMM404-HUB.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4CtNJ04MqBzXfV6; Sat, 12 Dec 2020 17:53:04 +0800 (CST) Received: from dggema771-chm.china.huawei.com (10.1.198.213) by DGGEMM404-HUB.china.huawei.com (10.3.20.212) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sat, 12 Dec 2020 17:53:35 +0800 Received: from dggemi751-chm.china.huawei.com (10.1.198.137) by dggema771-chm.china.huawei.com (10.1.198.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Sat, 12 Dec 2020 17:53:34 +0800 Received: from dggemi751-chm.china.huawei.com ([10.1.198.137]) by dggemi751-chm.china.huawei.com ([10.1.198.137]) with mapi id 15.01.1913.007; Sat, 12 Dec 2020 17:53:34 +0800 From: luyicai To: "Ananyev, Konstantin" , "dev@dpdk.org" CC: "Zhoujingbin (Robin, Russell Lab)" , chenchanghu , "Lilijun (Jerry)" , Linhaifeng , "Guohongzhi (Russell Lab)" , wangyunjian , "stable@dpdk.org" Thread-Topic: [PATCH v3] ip_frag: recalculate data length of fragment Thread-Index: AdbQbFntrZkGKmrfB0KwHVybXDeu1A== Date: Sat, 12 Dec 2020 09:53:34 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.243.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dpdk-stable] [PATCH v3] ip_frag: recalculate data length of fragment X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi, Thank you so much for your review! I absolutely agree with that, and I'll resubmit a patch as soon as possible. > -----Original Message----- > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com] > Sent: Monday, December 7, 2020 8:25 PM > To: luyicai ; dev@dpdk.org > Cc: Zhoujingbin (Robin, Russell Lab) ;=20 > chenchanghu ; Lilijun (Jerry)=20 > ; Linhaifeng ;=20 > Guohongzhi (Russell Lab) ; wangyunjian=20 > ; stable@dpdk.org > Subject: RE: [PATCH v3] ip_frag: recalculate data length of fragment > Hi, =20 > In some situations, we would get several ip fragments, which total=20 > data length is less than minimum frame(64) and padding with zeros. > Examples: Second Fragment "a0a1 a2a3 a4a5 a6a7 0000 0000 ..." > and Third Fragment "a8a9 aaab acad aeaf b0b1 b2b3 ...". > Finally, we would reassemble Second and Third Fragment like this > "a0a1 a2a3 a4a5 a6a7 0000 0000 ... a8a9 aaab acad aeaf b0b1 ...",=20 > which is not correct! > So, we need recalculate data length of fragment to remove padings! >=20 > Fixes: 7f0983ee331c ("ip_frag: check fragment length of incoming > packet") > Cc: stable@dpdk.org >=20 > Signed-off-by: Yicai Lu > --- > v2 -> v3: Update the comments. > --- > lib/librte_ip_frag/rte_ipv4_reassembly.c | 1 + > 1 file changed, 1 insertion(+) >=20 > diff --git a/lib/librte_ip_frag/rte_ipv4_reassembly.c > b/lib/librte_ip_frag/rte_ipv4_reassembly.c > index 1dda8aca0..9a9fe3703 100644 > --- a/lib/librte_ip_frag/rte_ipv4_reassembly.c > +++ b/lib/librte_ip_frag/rte_ipv4_reassembly.c > @@ -117,6 +117,7 @@ rte_ipv4_frag_reassemble_packet(struct > rte_ip_frag_tbl *tbl, >=20 > ip_ofs *=3D RTE_IPV4_HDR_OFFSET_UNITS; > ip_len =3D rte_be_to_cpu_16(ip_hdr->total_length) - mb->l3_len; > + mb->data_len =3D ip_len + mb->l3_len + mb->l2_len; > That doesn't look correct. > Even one fragment can consist of multiple segments. > Plus you don't update mb->pkt_len. > To do it properly, you'll need something like: > trim =3D mb->pkt_len - ip_len + mb->l3_len + mb->l2_len;=20 > rte_pktmbuf_trim(mb, trim); > Though my preference would be to leave it as responsibility of the=20 > caller (As it has to parse packet anyway to fill l2_len/l3_len and=20 > usually strips > l2 headers, etc). =20 >=20 > IP_FRAG_LOG(DEBUG, "%s:%d:\n" > "mbuf: %p, tms: %" PRIu64 > -- > 2.28.0.windows.1