From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 634EC37B2 for ; Mon, 15 Aug 2016 19:48:06 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id o80so117754112wme.1 for ; Mon, 15 Aug 2016 10:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=8UdDeCFKW+3YRk0z5ST1atxJ5bozMk8YAeogIDzSERQ=; b=EXIDHCICignojcKPVsOVfEDKFOmsxi6XGD2oiKFMdcCh+6tI2I06b1/swcSxgpcy24 njU+y6CPGBP2wsOyGb4KBHKz5YJbk6pOUBGUKP6WcIfnYEyeRfpewxljiR9tVNuS9bGd JyL2r0NzC3JLY7aLD2gQO23C6TfBWc8hd5yfOHW77VyXXv/rxAwEil07W7L9z+fxpSMD KelCoaRq3lmw2slyU1Jn0buBKY1nAN84rxP0g2WZ/nUXqSFEaCXfqP0dw7ncPmHguAq0 494WivRCWX2GhLt+99waQF+k6t68e/zb8CZ+lEBKp5lKFvvfIWI7GaNwGMjtM02Ob90u mB6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=8UdDeCFKW+3YRk0z5ST1atxJ5bozMk8YAeogIDzSERQ=; b=le5q2AeSD1WDdjuUG/oqS9XQdHfI85fgEPbLFnNVW20wNVMdP3hKBAoYXuMPJLiGLd JGPOGLdZOb6e8OuxkUrbKaKatlefZtXsT/J5gGFUFoYfkGp/C/grdIUdGcJjloveR3+C poK9RX9KSA8Wcxib5yRpwQj0TJTOdFiSzZXr/RbrhFSIraQvFSL+O+7+/CLCl39Yer5h h+gBYxi5jG76/CoKRt42QYljuO72bfZrvMBhacudkytl1XJRRncGwoxrYeBzKyaOkkaK /ENI2kRL2yPxVY2RIQSeWKy+Of93Ij6/goK9OoD6hiUoG9BU/ekgAhgCM+wbkBPZIAEf +zTg== X-Gm-Message-State: AEkoouuOk/tafgS0VuhOPAzAohWPTVrwgLYBOoU+jwkJCBi/zoIQpH0O3BEkZ7L0yKOq4LZibVAv4tIiwP8EsQ== X-Received: by 10.194.29.2 with SMTP id f2mr31791320wjh.161.1471283285799; Mon, 15 Aug 2016 10:48:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.11 with HTTP; Mon, 15 Aug 2016 10:48:04 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LjRgdC10LvQtdCy?= Date: Mon, 15 Aug 2016 20:48:04 +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: Re: [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:48:06 -0000 I'am sorry. Looks like having an mtu value multiply of 8 is a good practice= . But mtu value 1504 is also widely used in qinq linux interfaces. 2016-08-15 20:30 GMT+03:00 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4= =D1=80 =D0=9A=D0=B8=D1=81=D0=B5=D0=BB=D0=B5=D0=B2 : > 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 bac= k > 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= that > fragment size should be a multiply of 8, but what this line real checks i= s > 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 > > -- > -- > Kiselev Alexander > --=20 -- Kiselev Alexander