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 A08F7A0350 for ; Wed, 1 Jul 2020 18:48:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0FDAD1C28F; Wed, 1 Jul 2020 18:48:28 +0200 (CEST) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by dpdk.org (Postfix) with ESMTP id 03D911C295 for ; Wed, 1 Jul 2020 18:48:25 +0200 (CEST) Received: by mail-il1-f169.google.com with SMTP id a11so13394940ilk.0 for ; Wed, 01 Jul 2020 09:48:25 -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=jt0pdPWKl8nv4eDmzzolKlEZwNRBzRBYhQAQdgLadLc=; b=WNcL1YgV0j/mG2Z/Hd9PERnWaw16ZkFYelq25Dg1SK29xQn6OLj6ybdqaHKVEualG1 +1WYuZNCpXOsCkd6ZGcX5hyPzlbP6JSQaxAsnCrk4YBI3pybjJ9VPbUMxmbJT7B67knv uZGsmDAQe+C65p9m0JBLfQf8oQUICItHbbNEFrFixXtPOTpkZVB4Y+uGRACJoYBcBxaF 5fc6kfwYdAeiQBKYpQnMucrxgMHT/Iq02sPkIHMwxnIVMgdcErPVB5RgiZNgDhjW9O+h NtHP2S1uaa4SLN1/l2AtmLdo0zcAXDh8dbMbQIpTEg02xrX5K8fDpAowzCk9rfYvq4pq fLHA== 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=jt0pdPWKl8nv4eDmzzolKlEZwNRBzRBYhQAQdgLadLc=; b=k7QWAUicy2O8Bz3o23tU0FFCo+IsysKML1Lw5mRZy8v6KFSVKB9T9Wy9x0ElHC/E6b amLkIdIMKZOeqXK8AGoPjAjYOq+l18CEu5p5Pzt9pxugafJIyMinLjl8bgbkDWGt8Rq5 UI8PCp1W2A1NeiIfilLWb86SHxikiq9z6URXIQHwkWAUoJX9uePpJ+e4+664f1tPLVJM fNpiIOU4yIN1PyBmHrdMSh8kBt8mHCf/bDle5R3bfBLSy8jzFDMnj1u2Pbe/lrl479k0 2UQ7puM2WK51f9lvZkEBX2tSEWGrt2iKDm53Kv2sEj44dnIN986Sp+5tKTuGEchOVsru s3TA== X-Gm-Message-State: AOAM530hMgHLC6Pm+hSkFCnyTCi5kxDl8ds1qpeeiXWfJoV0mN52QXV6 9BvTABijZbwiTJOoPjUEZaDs5EGDgKEnOuFPBp0= X-Google-Smtp-Source: ABdhPJxwTufMGE50+fJhRgAqdWE2TF8OFabxHEwzD4Gy3KN6UohdRPdKkS07h9zcelKqt77v7qdXNtlpAM+iyLBnURw= X-Received: by 2002:a05:6e02:4ce:: with SMTP id f14mr8491133ils.2.1593622105235; Wed, 01 Jul 2020 09:48:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Aldrich Date: Wed, 1 Jul 2020 17:48:14 +0100 Message-ID: To: Matt Laswell 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" Hi Matt Thanks very much for your help. I was about to write out in more detail what our code does but I've just noticed that it uses a zero-copy method to attach a data buffer to the mbuf using a call to: rte_pktmbuf_attach() The docs says for this function: "Right now, not supported:" So maybe it doesn't work. Anyway, I need to revisit this code and take the simpler approach of just copying the payload into the mbuf. Maybe I can get the zero copy method working later. I'll see how this goes and come back if I need more help. David On Wed, Jul 1, 2020 at 4:56 PM Matt Laswell wrote: > OK, this makes sense. Understand that the mbuf data structure in DPDK > contains an offset that tells other consumers of the mbuf where to find > content. When you call rte_pktmbuf_prepend(), you're adjusting this > offset, in this case moving it forward by 42 bytes. > > Based on what I've seen you say here and on Stack Overflow, I think > perhaps your code is doing roughly this: > 1. You have an MBuf that contains your payload > 2. You create a second MBuf that contains your headers, and link it to the > payload mbuf via the ->next pointer and nb_segs > 3. But you then call rte_pktmbuf_prepend() on the payload MBuf, making > space in the payload MBuf for headers. > 4. You send the header payload, implicitly also sending the payload one > (since they're linked) > > If that's an accurate description of what you're doing, step 3 is the > problem. You're telling the transmitting NIC to start pulling 15 bytes of > payload from a spot that's 42 bytes ahead of where the payload actually > lives. Hence, you get whatever happens to be in the buffer at that point. > In this case, it's zeroes. It could be whatever garbage was lying around > from the last user of the MBuf. > > Let me know if that's an accurate description of what your application is > doing, or if I've misunderstood. > > On Wed, Jul 1, 2020 at 10:07 AM David Aldrich < > david.aldrich.ntml@gmail.com> 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. >> >> 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 < >> david.aldrich.ntml@gmail.com> >> > 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 < >> david.aldrich.ntml@gmail.com> >> >>> 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 >> >>>> >> >>> >> >