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 8C522A0A02; Fri, 15 Jan 2021 11:29:56 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4900F140EEE; Fri, 15 Jan 2021 11:29:56 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id 9A91C140ED4; Fri, 15 Jan 2021 11:29:55 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 3137F10B5; Fri, 15 Jan 2021 05:29:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 15 Jan 2021 05:29:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= FTY4pwKeOGdo8iCfTpcNBQOuukEQggxOVFh73Qm2I6s=; b=Fi/mA0qpVbkqq846 2PnKl64d2fVHZGmLg7rllow/3sHd+WfG25oEbq9XxIl0GRCp4KoMhAtOFgr6AE8n /p5OEvITwcg48qHDUPUQ287F4yiSSK6Vl+fIl8DnHSlt7097VB3PQkHrwhX+kMYn TRC7VN0n53FVp7yk7lhsK7xf42cxegF8GhECVwY6QGXwbYTh5kl3JVIQDUBo37FG lxF509JQlMWk/ja/pTN2YlHP84dhbYFw0vPtZPmBh2Nb1TY8v+dEd5vg6SRSUwN1 ZHdnCuZTLKawRJiSNTK4hMg2oefV0tfY1lzteAafhL08YYbqF+J6ZW9BFVz3taRU hXoBNQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=FTY4pwKeOGdo8iCfTpcNBQOuukEQggxOVFh73Qm2I 6s=; b=gN3I5iTcjhBNep/Bt9zfdg++WSsMh+NTcvZBxwwOE0TKSWJIH0fx9XWy2 mqLyr2hfmOVwmZythxctkKV9/U3slusIvzMRJ02O7gBD/Du0uH8DJ/4Hu3/3Ei9A jZflcVFaQmeuYTbhBfF2XzwZcIstU3uih5/JRVkJ9TEFA6cROnvzjMHPnBHdseBW JWiq0PvU9dnlkHpJd2OH23k0XdOLdP7/uPR6xaHn7IgolemS3P8ZycD+JVbaaXrb IupNuVv91t2SwjeRtGiC+FkbZ6U10+/cGsOPAHgy7juQWLO7pgS2SZlgXVcli7Yn QMIR8hispki6uUiuj8t88xo8IAntQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtddugddugeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 70D421080057; Fri, 15 Jan 2021 05:29:51 -0500 (EST) From: Thomas Monjalon To: Yicai Lu Cc: "dev@dpdk.org" , stable@dpdk.org, "zhoujingbin@huawei.com" , "chenchanghu@huawei.com" , "jerry.lilijun@huawei.com" , "haifeng.lin@huawei.com" , "guohongzhi1@huawei.com" , "wangyunjian@huawei.com" , "Ananyev, Konstantin" Date: Fri, 15 Jan 2021 11:29:49 +0100 Message-ID: <1911696.HhHb5bI1x5@thomas> In-Reply-To: References: <1605706193-17192-1-git-send-email-luyicai@huawei.com> <1608125790-26496-1-git-send-email-luyicai@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v6] ip_frag: remove padding length of fragment 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" > > In some situations, we would get several ip fragments, which total > > data length is less than min_ip_len(64) and padding with zeros. > > We simulated intermediate fragments by modifying the MTU. > > To illustrate the problem, we simplify the packet format and > > ignore the impact of the packet header.In namespace2, > > a packet whose data length is 1520 is sent. > > When the packet passes tap2, the packet is divided into two > > fragments: fragment A and B, similar to (1520 = 1510 + 10). > > When the packet passes tap3, the larger fragment packet A is > > divided into two fragments A1 and A2, similar to (1510 = 1500 + 10). > > Finally, the bond interface receives three fragments: > > A1, A2, and B (1520 = 1500 + 10 + 10). > > One fragmented packet A2 is smaller than the minimum Ethernet > > frame length, so it needs to be padded. > > > > |---------------------------------------------------| > > | HOST | > > | |--------------| |----------------------------| | > > | | ns2 | | |--------------| | | > > | | |--------| | | |--------| |--------| | | > > | | | tap1 | | | | tap2 | ns1| tap3 | | | > > | | |mtu=1510| | | |mtu=1510| |mtu=1500| | | > > | |--|1.1.1.1 |--| |--|1.1.1.2 |----|2.1.1.1 |--| | > > | |--------| |--------| |--------| | > > | | | | | > > | |-----------------| | | > > | | | > > | |--------| | > > | | bond | | > > |--------------------------------------|mtu=1500|---| > > |--------| > > > > When processing the preceding packets above, > > DPDK would aggregate fragmented packets A2 and B. > > And error packets are generated, which padding(zero) > > is displayed in the middle of the packet. > > > > A2 + B: > > 0000 fa 16 3e 9f fb 82 fa 47 b2 57 dc 20 08 00 45 00 > > 0010 00 33 b4 66 00 ba 3f 01 c1 a5 01 01 01 01 02 01 > > 0020 01 02 c0 c1 c2 c3 c4 c5 c6 c7 00 00 00 00 00 00 > > 0030 00 00 00 00 00 00 00 00 00 00 00 00 c8 c9 ca cb > > 0040 cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db > > 0050 dc dd de df e0 e1 e2 e3 e4 e5 e6 > > > > So, we would calculate the length of padding, and remove > > the padding in pkt_len and data_len before aggregation. > > And also we have the fix for both ipv4 and ipv6. > > > > Fixes: 7f0983ee331c ("ip_frag: check fragment length of incoming packet") > > Cc: stable@dpdk.org > > > > Signed-off-by: Yicai Lu > > Acked-by: Konstantin Ananyev Applied, thanks