From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by dpdk.org (Postfix) with ESMTP id C94CC5A30 for ; Fri, 12 Aug 2016 19:45:00 +0200 (CEST) Received: by mail-io0-f180.google.com with SMTP id 38so31230975iol.0 for ; Fri, 12 Aug 2016 10:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinite-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9hNkvKqc7TPqRRJ3GOLuOwrveb9zA6CO15BlmgFVQKI=; b=H5tjfR0hT2B4scZBtZwXAejwI7sHQYYbcNVdVAmxosiAl5A4iBYtNXszSui7WhQzri GqvF0ii8/PI6iq1HwBDOoWWUg5bjkgZkTsHl+X81YOAloURDi9ST7cQwIAwhut18G53m TYyOOWPQNluC+RmUlgbhy4qqbxuEES51LQYwM1elQrt9J2pzHZtZp/sSFyRrGl+G9YAR CS++Di41gF8Ilwtchh/zyK1oO7mEFVQEYioi5zBUHghgnBJXyoprAEDp5QCR5xPL760s dgevqkgHHdD7mipXUbNxezGR0E4l6G1uq5UfFG3hNzV8sVnTAGJIUp+vjNenwOlYLVDy eDrA== 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:cc; bh=9hNkvKqc7TPqRRJ3GOLuOwrveb9zA6CO15BlmgFVQKI=; b=QbfGo+kdo9uoQXMu7Ty8HNSjFy6Poi9DwV45IUKR/fh6UcJhRkuu0l1lyitWoRPrJX OiT+iK/Tz3ScYu0U9XTx8PT5BwtIoWsjLUVWLDN5h7FQHy3O3l/xprDjC5v/my93da26 7GX2vFgunXzxVyy1EkrqeNpjQjhFTKw5t3bAgPR8XOHeXO0nKupY4Q6A4s1W1zwCrgP4 CuwXPfiJr6X2CPadpz41lecTEMekPyNMu+L8PQwdGtPp2Rom8Ec8rWwXNf8fsCbwWc/k 03vakAKx0+EP1KkkkZUdeLf4p2Gtk6zBTx5ch37RhOdP05Q1htjU3licH8atCnfXXatS 1y3g== X-Gm-Message-State: AEkooutyfWEFMEpoXUr3Njeh4szeOXmYJRAodDhy5ogQG6FClSA88Iu8QLU4klDzRiUWf2DmCZeFnWtz02GHSQ== X-Received: by 10.107.138.102 with SMTP id m99mr20129906iod.91.1471023900227; Fri, 12 Aug 2016 10:45:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.68 with HTTP; Fri, 12 Aug 2016 10:44:59 -0700 (PDT) In-Reply-To: References: From: Matt Laswell Date: Fri, 12 Aug 2016 12:44:59 -0500 Message-ID: To: =?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LjRgdC10LvQtdCy?= Cc: users Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] ipv4 fragmentation X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 17:45:01 -0000 I've found that if both the packet length and data length fields in an mbuf aren't set properly, DPDK will quietly drop it on the floor when I try to send it. I don't know if that's the cause of your problems, but it's one of the first places that I would look. -- Matt Laswell Principal Software Engineer, infinite io laswell@infinite.io On Fri, Aug 12, 2016 at 12:32 PM, =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 wrote: > Hi! > > I am trying to use rte_ipv4_fragment_packet() function, but so far all > attemps has been unsuccessful. > > Fragment function gets a packet, successfuly splits it to the two packets= , > then I add an L2 header to the each of resulting fragments > and send the fragments using rte_eth_tx_burst() to the wire. All steps of > the above process are succesfully completed without any error, but I don'= t > see the fragments on the wire and PMD stat function also reports that no > packets were transmitted. > > I've rechecked many times that L2 header of each fragments is correct, th= at > values of l2_len and l3_len rte_mbuf members are correct, > that the rte_eth_tx_burst() result is correct (2 packets). The sizes of > fragments are also correct. > > What did I miss? > > I am using DPDK 2.2.0 and ixgbe PMD driver. > > This is some log data of a test run. > =3D=3D > =3D=3D > The original packet that has to be fragmented (including L2 header data) > > dump mbuf at 0x0x7f7d103870c0, phys=3D215787140, buf_len=3D2176 > pkt_len=3D2546, ol_flags=3D40000000000003, nb_segs=3D2, in_port=3D0 > segment at 0x0x7f7d103870c0, data=3D0x0x7f7d103871c0, data_len=3D1518 > Dump data at [0x7f7d103871c0], len=3D50 > 00000000: 00 1B 21 3C 69 45 90 E2 BA 00 3C CC 81 00 00 86 | > ..! 00000010: 08 00 45 00 09 E0 7E D1 00 00 40 01 00 00 C0 A8 | > ..E...~...@..... > 00000020: 7D 01 C0 A8 7D 02 00 00 FD FD 0B 2D 00 01 56 FF | > }...}......-..V. > 00000030: AD 57 | | | | | | | | | | | | | | | .W > segment at 0x0x7f7d10386780, data=3D0x0x7f7d103868a6, data_len=3D1028 > > > fragmentation is needed. mtu 1500, pkt len 2546, data len 1518, l2 len 18= , > l3 len 20 > num fragment needed: 2 > > =3D=3D > =3D=3D > Fragments (including L2 header data): > > fragment #0, pkt len 1518, l2 len 18, l3 len 20, data len 38 > > dump mbuf at 0x0x7f7d10388340, phys=3D2157883c0, buf_len=3D2176 > pkt_len=3D1518, ol_flags=3D40000000000000, nb_segs=3D2, in_port=3D255 > segment at 0x0x7f7d10388340, data=3D0x0x7f7d1038842e, data_len=3D38 > Dump data at [0x7f7d1038842e], len=3D38 > 00000000: 00 1B 21 3C 69 45 90 E2 BA 00 3C CC 81 00 00 86 | > ..! 00000010: 08 00 45 00 05 DC 7E D1 20 00 40 01 00 00 C0 A8 | ..E...~. > .@..... > 00000020: 7D 01 C0 A8 7D 02 | | | | | | | | | | | }...}. > segment at 0x0x7f7d0ef87dc0, data=3D0x0x7f7d103871e6, data_len=3D1480 > Dump data at [0x7f7d103871e6], len=3D12 > 00000000: 00 00 FD FD 0B 2D 00 01 56 FF AD 57 | | | | | .....-..V..W > > > fragment #1, pkt len 1066, l2 len 18, l3 len 20, data len 38 > > dump mbuf at 0x0x7f7d10388c80, phys=3D215788d00, buf_len=3D2176 > pkt_len=3D1066, ol_flags=3D40000000000000, nb_segs=3D2, in_port=3D255 > segment at 0x0x7f7d10388c80, data=3D0x0x7f7d10388d6e, data_len=3D38 > Dump data at [0x7f7d10388d6e], len=3D38 > 00000000: 00 1B 21 3C 69 45 90 E2 BA 00 3C CC 81 00 00 86 | > ..! 00000010: 08 00 45 00 04 18 7E D1 00 B9 40 01 00 00 C0 A8 | > ..E...~...@..... > 00000020: 7D 01 C0 A8 7D 02 | | | | | | | | | | | }...}. > segment at 0x0x7f7d0ef87480, data=3D0x0x7f7d103868a6, data_len=3D1028 > Dump data at [0x7f7d103868a6], len=3D12 > 00000000: C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB | | | | | ............ > lcore 1 SEND > > =3D=3D > =3D=3D > sending 2 packets > sending result: 2 > > > -- > -- > Kiselev Alexander >