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 A887DA0350 for ; Wed, 1 Jul 2020 17:06:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8A0D01D502; Wed, 1 Jul 2020 17:06:57 +0200 (CEST) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by dpdk.org (Postfix) with ESMTP id 3E3951D449 for ; Wed, 1 Jul 2020 17:06:56 +0200 (CEST) Received: by mail-io1-f44.google.com with SMTP id q8so25354269iow.7 for ; Wed, 01 Jul 2020 08:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ciIzX79pADzKoyaQ4cwlri2NcOtVpSocJmnGM0HURzQ=; b=tna3minPC38otFhihuHm7iRA5hPuqYb2cBSFrtlqc4tz8jv/g+kB0WDAyeGWB8p/8j D9eldb/l0oN7Ibc856sqA0ILoSYIAv7lzcpvHCyefbbZiyVYPnIhpV6ET682yGaz5Zei 0shucWDzj8LtNEPEOAsotLmP9EkONLW3qkOW1iPSCsdooJDrh8E/P2s1D/biUhVzT9q6 RJgntIZJJHViWE7N1MhnOJkgLag5DAF+qeBmcRLfZdz0fgYCn2WoNnc3Og35D7HmaGM1 hRNQskkQxpuFlrO0sq55q1vz27edHPEy0Ksn26GsdUrtUFCTfFPsumSxh7yaXBJSGrva ly0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ciIzX79pADzKoyaQ4cwlri2NcOtVpSocJmnGM0HURzQ=; b=N1LxLv65fr9p6FawUEuEIWVM91oNAhnDFQGxnCjJzjoxhKpHTChHJEDRPUzbXHWDbd zTk7ppAclG5g/asaO6SwT+pxRac00s4sAebluNPzTEvfBG8DgyOJcd5Ne7k4ANIwUOvX nXt/8q1fuFtAPbOuXSKAfuIWFDKmjsJ/AR7vkS+r8ay6Nf2yMNbvgNz0jZl255Gh5PM+ 9wKY4dRGdcnrjp5JghnuihwElB5oXyvI0uIpf2LMJLLzhkwra98ZuwtmHDJgNDhBN4Dp oZXMnJs67v9l7nlSLxPczBXei5Pgcy5ZNQszurV9fO7J2Io9tzFb3cW5LGYsj9mGYYt1 YY3g== X-Gm-Message-State: AOAM5312wgZ2k+4hbl/RpDbnFIt/0YIcRiP426x6MzbNHzZU/mrMfhmF 5PE9Z9KwzC4GdCbhqAjmlnDJbUZk+fkRdH7XWKI= X-Google-Smtp-Source: ABdhPJwuIuVD97XMzcAEk6gl4ZfLtkbdTXYGVtamLFgqFuzMmsLHJzRgsg1H9Yzc8K9Q0kaZzecy16jBTbefnKX7UrI= X-Received: by 2002:a02:6d1b:: with SMTP id m27mr13822395jac.129.1593616015585; Wed, 01 Jul 2020 08:06:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Aldrich Date: Wed, 1 Jul 2020 16:06:44 +0100 Message-ID: To: Cliff Burdick Cc: users Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Why is udp packet, sent by dpdk, received with zero'd payload? X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" >If you look at the code for rte_pktmbuf_prepend it appears to be just >incrementing data_len and pkt_len by the same amount. I'm sorry, but I don't understand. My calls to rte_pktmbuf_prepend are: p_udp_hdr = (struct udp_hdr*)rte_pktmbuf_prepend(ptMbuf, (uint16_t)sizeof(struct udp_hdr)); p_ip_hdr = (struct ipv4_hdr*)rte_pktmbuf_prepend(ptMbuf, (uint16_t)sizeof(struct ipv4_hdr)); are you saying that those calls are wrong? When you say 'if you look at the code' are you referring to this code? (I thought it best that I should ask for clarification rather than guess). Thanks On Wed, Jul 1, 2020 at 3:59 PM Cliff Burdick wrote: > If you look at the code for rte_pktmbuf_prepend it appears to be just > incrementing data_len and pkt_len by the same amount. My guess is that > those fields were not set to the correct values before you called > rte_pktmbuf_prepend(). > > On Wed, Jul 1, 2020 at 6:41 AM David Aldrich > wrote: > >> I think this is where my lack of understanding is my problem. Looking at >> the mbuf dump: >> >> dump mbuf at 0x53e4e92c0, iova=73e4e9340, buf_len=2176 >> pkt_len=57, ol_flags=c0000000000000, nb_segs=2, in_port=65535 >> segment at 0x53e4e92c0, data=0x53e4e9396, data_len=42 >> Dump data at [0x53e4e9396], len=42 >> 00000000: 94 40 C9 1F C4 DB 94 40 C9 1E 13 7D 08 00 45 B8 | .@.....@...}..E. >> 00000010: 00 2B 00 00 00 00 40 11 F5 E8 C0 A8 01 69 C0 A8 | .+....@......i.. >> 00000020: 01 68 0B B9 0B B8 00 17 64 2D | | | | | | | .h......d- >> segment at 0x53e146e40, data=0x53e4fbbc0, data_len=15 >> Dump data at [0x53e4fbbc0], len=15 >> 00000000: 48 65 6C 6C 6F 20 66 72 6F 6D 20 64 70 64 6B | | Hello from dpdk >> >> It consists of two parts (segments?), of lengths 42 and 15. This makes sense to me as I first >> put the payload in the mbuf (15 bytes) and then added the Ethernet and L3 headers (42 bytes) by calling rte_pktmbuf_prepend(). >> >> I guess only the first segment is getting transmitted? >> >> >> On Wed, Jul 1, 2020 at 1:57 PM Cliff Burdick wrote: >> >>> Are you setting data_len and packet_len in the mbuf before sending? >>> >>> >>> On Wed, Jul 1, 2020, 03:23 David Aldrich >>> wrote: >>> >>>> Hi, >>>> >>>> I have a problem transmitting udp packets with dpdk-stable-18.11.8. I >>>> have >>>> posted a question about it on stackoverflow: >>>> >>>> >>>> https://stackoverflow.com/questions/62674596/why-is-udp-packet-sent-by-dpdk-received-with-zerod-payload >>>> >>>> I would be grateful for any comments either there or in this group >>>> please. >>>> >>>> Best regards >>>> >>>> David >>>> >>>