From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 00A682B88 for <dev@dpdk.org>; Mon, 22 Aug 2016 13:31:15 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id i5so138855711wmg.0 for <dev@dpdk.org>; Mon, 22 Aug 2016 04:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=iW1TuZC8wCX6xKSUUSoZUyXNcJFWdMe0JEGL2AIaHj8=; b=Y5NHb7X+U3Hl5VTP1UvfKWB8VpTraDuKOhqVBTD1m2viLJvDSJRCSuMBqsbhXgAueA 4RDsnJzZyh+tHvFeBbrjSJ/jOYWunjExGDvB/lbrqAUvINxnQAOLOCkxhMENjHsE15U5 2Ze6+Ci6o09EG8NO4RjYyNaYPL093cPSrRl5GHmLAr8rDP5D2zeW0uc67no3RPE+omAg 6hQung4PrqbDuqzHYTuJR0JfYWJkgBj4OzY5dK9UxiNDsr1BSLQGjdCQmwFBmoX/Zx8m iIBoeKn2NUqadzi2aVVcL4MUMwFo/ip4an278BP0f/CnnsHQ6yFfE3w5bo+4SjWQh5pk g/nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=iW1TuZC8wCX6xKSUUSoZUyXNcJFWdMe0JEGL2AIaHj8=; b=bEaVEYIAHROwTBthgmJBE2kVn4ddYIy/wu0IhHwfttF2MSrhDiC8VnXG0K8sj+Xi77 RUMq+yT1Sn2gyfD6nf6SPNVt8IFZoOqqSXPzbbvxuYWY0Ayr7Oleop4h5kuTAnrkCGns nP0FH1kFli9ylsCzSxGJbxAuESghdiSYI5j94/ePTfxHjz07tVXTd3vkpL1CdZbNZlYp qlcrIQRTlz7FacqNMeyRq2s8I0JqCBLgRvWbppJk3hnXN/DismWUFls3EU17T7mycTSr ynIerjnNkzZcvLxI6/78wOWuK2Lb0V2tN9biM4W5BH0e2oCo+lHhb/4AU3GxGpR9sVDv Zwbw== X-Gm-Message-State: AEkoouunqnHxUlIgSGJP2Irzhm9qYg+E+UJ+ecnzUxmXHMtD4I8OAWqeqK4N8ff3cqzZ6aDZ X-Received: by 10.194.144.33 with SMTP id sj1mr16287701wjb.150.1471865474721; Mon, 22 Aug 2016 04:31:14 -0700 (PDT) Received: from xps13.localnet (171.17.90.79.rev.sfr.net. [79.90.17.171]) by smtp.gmail.com with ESMTPSA id q4sm23510218wjk.24.2016.08.22.04.31.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Aug 2016 04:31:14 -0700 (PDT) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: =?utf-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LjRgdC10LvQtdCy?= <kiselev99@gmail.com> Cc: dev@dpdk.org Date: Mon, 22 Aug 2016 13:31:12 +0200 Message-ID: <13658731.5PNXAK9RiV@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <CAMKNYby4g_Oi68E7x1=G1+3nLMfpVkZ_UMkZdWf5GiRQHApaAA@mail.gmail.com> References: <CAMKNYbx3g1Ft+ZuTtwu7ai_dYyHhs6pPWjd5B=Pv0qSB0zG-Mg@mail.gmail.com> <CAMKNYby4g_Oi68E7x1=G1+3nLMfpVkZ_UMkZdWf5GiRQHApaAA@mail.gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 22 Aug 2016 11:31:15 -0000 Hi, > 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 <kiselev99@gmai= l.com>: > > While playing with function rte_ipv4_fragment_packet I found that i= t > > incorrectly fragments packets. > > For example if the function takes 1200 bytes packet and mtu size 10= 00 it > > will produces two fragments. And when those fragments are reassembl= ed 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 tru= ncated. > > 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 ch= ecks is > > that > > the size of mtu minus 20 bytes should be multiply of 8. In other wo= rds > > it constrains the size of the mtu. So, if I take valid mtu value, s= ay > > 1504, > > it will produce incorrect fragments when asserts are off. Thanks for reporting. 2016-08-15 20:48, =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: > I'am sorry. Looks like having an mtu value multiply of 8 is a good pr= actice. >=20 > But mtu value 1504 is also widely used in qinq linux interfaces. Please, would like to write a patch for master branch? Or do you prefer to delegate it to someone reading this thread?