From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 90EF5A04F2; Fri, 6 Dec 2019 17:26:01 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BFA1D1BF92; Fri, 6 Dec 2019 17:26:00 +0100 (CET) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) by dpdk.org (Postfix) with ESMTP id CCCD41BF90 for ; Fri, 6 Dec 2019 17:25:58 +0100 (CET) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xB6GEfcn118307 for ; Fri, 6 Dec 2019 16:25:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type; s=corp-2019-08-05; bh=rmMMRllN85AIvAhPn6OHwmd/8WZUkRD2zIxbFjlXT98=; b=SbPsw+WiJr7DeV4Xn6wmzXMYWsBS+blDO3SHyRH0bB12e9p7oCprwjuGIsOWh5Z4WjOq nhVibLGaMcJuNiPaEyHx4z0zPBZal3A+GOjJi48c2CKK4Qeyy0QhgPidouqk5GwH37Bi n1FaEqwA+qzay3GEDE7bBXokAOBiHfvBcE42D1aaPL25zKiN89RLm9LSyqnChvWilb8F SnWDvsF6eBFc8Ir3ipY0cNmVHdsJIEJjGZo0HnAQk71FUE6mIKVAKQ83xpp5X4zat4ah Z6sSq5KdoswpKuYgXfHQnaPSxueJcEtN7bNof5UEQttyBoxm1FS5EWYtpBQyx4eHgeMO lw== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 2wkgcqw1w9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 06 Dec 2019 16:25:57 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xB6GDj5Y132561 for ; Fri, 6 Dec 2019 16:25:57 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2wqeraqnbd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 06 Dec 2019 16:25:56 +0000 Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xB6GPt6b023374 for ; Fri, 6 Dec 2019 16:25:55 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 6 Dec 2019 08:25:53 -0800 (PST) From: Steve Banville To: dev@dpdk.org References: <0048e9d0-1367-4314-a703-c6d90dae1822@default> In-Reply-To: <0048e9d0-1367-4314-a703-c6d90dae1822@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 15.0.5172.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9463 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912060136 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9463 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912060136 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] FW: IP fragmentation chunk getting dropped on egress X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" =20 Hi, =20 I'm seeing an issue with DPDK and IP frag where the first chunk is getting = dropped on egress. I'm using the igb_e1000 driver with DPDK v18.x. My scena= rio is that I'm allocating a new buffer to store an outer L3 tunnel header,= I clone the original received buffer which is a little over 3K, I link the= newly cloned buffer to the allocated buffers nextptr and copy the meta dat= a from the original packet buffer to the new allocated buffer. After callin= g rte_ipv4_fragment_packet, I notice that the number of chunks created fo= rm the jumbo packet seems correct. What's strange is that the 1st fragmente= d chunk has a segment with a data_len =3D 0. All subsequent chunks appear t= o be fine. I've ran rte_mbuf_sanity_check against my new packet which succe= eds. After adjusting the packet for L2 and adding the Ethernet header, I se= nd the packet out but only chunks 1 + 2 are received off the wire. The firs= t chunk (0) is never received and the NICs eth stats reflect this as well. =20 =20 I'm hoping someone could shed some light on this issue and provide a soluti= on. =20 Thanks, =20 Steve =20 Code example: =20 copybuf =3D rte_pktmbuf_alloc(getMbufPool()); // Add L3 tunnel header Clone_buffer =3D rte_pktmbuf_clone(pkt_info->mblk, getClonePool()); =20 =20 // Link the outer trace header copybuf->next =3D clone_buffer; copybuf->pkt_len +=3D clone_buffer->pkt_len; // update ov= erall packet length clone_buffer->pkt_len =3D clone_buffer->data_len; // packet le= n only in first segment =20 copybuf->nb_segs =3D (uint8_t)(clone_buffer->nb_segs + 1); =20 =20 /* copy metadata from source packet */ copybuf->vlan_tci =3D pkt_info->mblk->vlan_tci; copybuf->vlan_tci_outer =3D pkt_info->mblk->vlan_tci_outer; copybuf->port =3D pkt_info->mblk->port; copybuf->tx_offload =3D pkt_info->mblk->tx_offload; =20 copybuf->hash =3D pkt_info->mblk->hash; copybuf->ol_flags =3D pkt_info->mblk->ol_flags; =20 rte_mbuf_sanity_check(copybuf, 1); =20 =20 Rice# dump mbuf at 0x3100ae8e56c0, iova=3D42e8e5880, buf_len=3D2176 pkt_len=3D3687, ol_flags=3D182, nb_segs=3D4, in_port=3D0 segment at 0x3100ae8e56c0, data=3D0x3100ae8e5900, data_len=3D20 Dump data at [0x3100ae8e5900], len=3D20 00000000: 45 00 0E 67 00 00 00 00 80 04 82 0B C0 A8 94 6E | E..g...........= n 00000010: C0 A8 94 C8 | | | | | | | | | | | | | .... segment at 0x3100a6f319c0, data=3D0x3100a73b9b0e, data_len=3D1500 Dump data at [0x3100a73b9b0e], len=3D80 00000000: 45 00 0E 53 27 22 00 00 40 11 C4 DE AC 10 94 0A | E..S'"..@......= . 00000010: AC 10 94 6E 13 C4 13 C4 0E 3F 00 1F 49 4E 56 49 | ...n.....?..INV= I 00000020: 54 45 20 73 69 70 3A 73 65 72 76 69 63 65 40 31 | TE sip:service@= 1 00000030: 37 32 2E 31 36 2E 31 34 38 2E 31 31 30 3A 35 30 | 72.16.148.110:5= 0 00000040: 36 30 20 53 49 50 2F 32 2E 30 0D 0A 56 69 61 3A | 60 SIP/2.0..Via= : segment at 0x3100a6f31900, data=3D0x3100a73b90a2, data_len=3D1480 segment at 0x3100a6f31840, data=3D0x3100a73b8622, data_len=3D687 =20 Chunk 0: l2 len 0 l3 len 20, pkt len 1514, data len 34, nsegs 3 dump mbuf at 0x3100ae8e4c40, iova=3D42e8e4e00, buf_len=3D2176 pkt_len=3D1514, ol_flags=3D40000000000000, nb_segs=3D3, in_port=3D65535 segment at 0x3100ae8e4c40, data=3D0x3100ae8e4e72, data_len=3D34 Dump data at [0x3100ae8e4e72], len=3D34 00000000: 00 21 F6 69 02 A3 00 08 25 25 63 A4 08 00 45 00 | .!.i....%%c...E= . 00000010: 05 DC FA CF 20 00 80 04 6F C6 C0 A8 94 6E C0 A8 | .... ...o....n.= . 00000020: 94 C8 | | | | | | | | | | | | | | | .. segment at 0x3100ae8e41c0, data=3D0x3100ae8e5914, data_len=3D0 segment at 0x3100ae8e3740, data=3D0x3100a73b9b0e, data_len=3D1480 Dump data at [0x3100a73b9b0e], len=3D66 00000000: 45 00 0E 53 27 22 00 00 40 11 C4 DE AC 10 94 0A | E..S'"..@......= . 00000010: AC 10 94 6E 13 C4 13 C4 0E 3F 00 1F 49 4E 56 49 | ...n.....?..INV= I 00000020: 54 45 20 73 69 70 3A 73 65 72 76 69 63 65 40 31 | TE sip:service@= 1 00000030: 37 32 2E 31 36 2E 31 34 38 2E 31 31 30 3A 35 30 | 72.16.148.110:5= 0 00000040: 36 30 | | | | | | | | | | | | | | | 60 Sending packet: txQ 1, L2 len 14, L3 len 20, protocol 4, flags 0 mtu 1500 e= gress intf 537919488 =20 Chunk 1: l2 len 0 l3 len 20, pkt len 1514, data len 34, nsegs 3 dump mbuf at 0x3100ae8e2cc0, iova=3D42e8e2e80, buf_len=3D2176 pkt_len=3D1514, ol_flags=3D40000000000000, nb_segs=3D3, in_port=3D65535 segment at 0x3100ae8e2cc0, data=3D0x3100ae8e2ef2, data_len=3D34 Dump data at [0x3100ae8e2ef2], len=3D34 00000000: 00 21 F6 69 02 A3 00 08 25 25 63 A4 08 00 45 00 | .!.i....%%c...E= . 00000010: 05 DC FA CF 20 B9 80 04 6F 0D C0 A8 94 6E C0 A8 | .... ...o....n.= . 00000020: 94 C8 | | | | | | | | | | | | | | | .. segment at 0x3100ae8e2240, data=3D0x3100a73ba0d6, data_len=3D20 Dump data at [0x3100a73ba0d6], len=3D20 00000000: 37 32 2E 31 36 2E 31 34 38 2E 31 30 3A 35 30 36 | 72.16.148.10:50= 6 00000010: 30 3E 3B 72 | | | | | | | | | | | | | 0>;r segment at 0x3100ae8e17c0, data=3D0x3100a73b90a2, data_len=3D1460 Dump data at [0x3100a73b90a2], len=3D46 00000000: 65 61 73 6F 6E 3D 74 69 6D 65 2D 6F 66 2D 64 61 | eason=3Dtime-of= -da 00000010: 79 0D 0A 44 69 76 65 72 73 69 6F 6E 3A 20 3C 73 | y..Diversion: <= s 00000020: 69 70 3A 73 69 70 70 30 30 30 31 38 40 31 | | | ip:sipp00018@1 Sending packet: txQ 1, L2 len 14, L3 len 20, protocol 4, flags 0 mtu 1500 e= gress intf 537919488 =20 Chunk 2: l2 len 0 l3 len 20, pkt len 741, data len 34, nsegs 3 dump mbuf at 0x3100ae8e0d40, iova=3D42e8e0f00, buf_len=3D2176 pkt_len=3D741, ol_flags=3D40000000000000, nb_segs=3D3, in_port=3D65535 segment at 0x3100ae8e0d40, data=3D0x3100ae8e0f72, data_len=3D34 Dump data at [0x3100ae8e0f72], len=3D34 00000000: 00 21 F6 69 02 A3 00 08 25 25 63 A4 08 00 45 00 | .!.i....%%c...E= . 00000010: 02 D7 FA CF 01 72 80 04 91 59 C0 A8 94 6E C0 A8 | .....r...Y...n.= . 00000020: 94 C8 | | | | | | | | | | | | | | | .. segment at 0x3100ae8e02c0, data=3D0x3100a73b9656, data_len=3D20 Dump data at [0x3100a73b9656], len=3D20 00000000: 6D 65 2D 6F 66 2D 64 61 79 0D 0A 44 69 76 65 72 | me-of-day..Dive= r 00000010: 73 69 6F 6E | | | | | | | | | | | | | sion segment at 0x3100ae8df840, data=3D0x3100a73b8622, data_len=3D687 Dump data at [0x3100a73b8622], len=3D46 00000000: 3A 20 3C 73 69 70 3A 73 69 70 70 30 30 30 34 30 | : ;reason=3Dt= i Sending packet: txQ 1, L2 len 14, L3 len 20, protocol 4, flags 0 mtu 1500 e= gress intf 537919488 =20 =20 =20 Stephen Banville | Consulting Software Engineer Phone: +1 781-538-7670 100 Crosby Drive | Bedford, MA 01730 CGBU DEV - Platform Engineering https://oracle.zoom.us/my/steve.banville _____ =20 =20