From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id F07395591 for ; Mon, 15 Aug 2016 19:30:59 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id i5so116897565wmg.0 for ; Mon, 15 Aug 2016 10:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=JoQrEmec5A7xy2oX9ilUaNhhO/F7gV/6rBQ9stP3PhY=; b=Dz57LV1/ejkAZZim0tB+txOAvQ6ONFWBrwyz+vFKtYA9ScnCrD8XtGtygVCOs9xseg VYZ2eKxw3XG5Z9Y4jiqheJ8Oj53ZeMYC4/9qcGurSEpwpkPFEMRJqWdZblM3yWPSjWHs NqlLtZ/NHu+UWuT6ZJPpdyiD8Kj4Ckqf9qd23Kx/dtcwXtSPCLUsc2/CVJsWa6AS8PF5 mwcNxKgHmRZajt00GWYEDz+k3lkHfEKHdQ/fHmIZr7Ouib+h1LSwclQbJ8/VsqiwCqNL cXax2RFaDQ0F6vn5mi6NkBe7Iad5e2B4lSDuTE5Qf9SuQ1C3CDI8AqeIcvGcFABQYa07 cJAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JoQrEmec5A7xy2oX9ilUaNhhO/F7gV/6rBQ9stP3PhY=; b=VmNFvAbU6z5g1/MFy0PF7cNnqPHUeD5MgZ+cLmA4vLIcJjSTFYqm4YJ9I8Dto+4Saa I0xG6A0u9jcMRJn0YZim6UBBDPMGE5omCgfLx4LT3b+/EPeaSHavZ0NAtugPC6JkLjAd oUC1eYd7ejI4mVTn+q5mYK/qvHVZjjQQxfSxMHxsdOcNH3qgUUAEcM3Ii7niLSsj01kO q0VBgAkZraJUElSifBlgEqETM5ZN+ypCk7DOkSW26bXmEC6pi1y0BteXeWLiLa2fjaTj 3HtWFbWXAbZhMBXX7ExzP7oApUIEiQ9UgnOr9YJe6mq5pDLP8C2cWwNFaedW8ayia7Tj tt4w== X-Gm-Message-State: AEkoout+ThzYXMiaxWPLHJ3bmk/2nC2grq1yNDYwhB5yNw0gK/Ywg3AeRR09qUtp+1dmOtkIFwYb6fLRfe1s5g== X-Received: by 10.28.129.137 with SMTP id c131mr15069722wmd.79.1471282259349; Mon, 15 Aug 2016 10:30:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.11 with HTTP; Mon, 15 Aug 2016 10:30:58 -0700 (PDT) From: =?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LjRgdC10LvQtdCy?= Date: Mon, 15 Aug 2016 20:30:58 +0300 Message-ID: To: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] ipv4 fragmentation bug? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 17:31:00 -0000 While playing with function rte_ipv4_fragment_packet I found that it incorrectly fragments packets. For example if the function takes 1200 bytes packet and mtu size 1000 it will produces two fragments. And when those fragments are reassembled back the resulting packet will be 4 bytes shorter than it should be. I played with linux ping program and it reports that a reply is truncated. 1204 bytes from 192.168.125.1: icmp_seq=3D1 ttl=3D64 (truncated) Looking at the source of rte_ipv4_fragment_packet I discovered the cause of the above behavior. Function makes the following assumption and the whole calculations are bases on that assumption. /* Fragment size should be a multiply of 8. */ IP_FRAG_ASSERT((frag_size & IPV4_HDR_FO_MASK) =3D=3D 0); The problem is that this assert doesn=E2=80=99t make any sense. It's true t= hat fragment size should be a multiply of 8, but what this line real checks is that the size of mtu minus 20 bytes should be multiply of 8. In other words it constrains the size of the mtu. So, if I take valid mtu value, say 1504, it will produce incorrect fragments when asserts are off. P.S. I am using DPDK v 2.2.0 --=20 -- Kiselev Alexander