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 DA5FAA0350 for ; Wed, 1 Jul 2020 19:57:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3FB071C1D9; Wed, 1 Jul 2020 19:57:48 +0200 (CEST) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by dpdk.org (Postfix) with ESMTP id 86AD51C1D0 for ; Wed, 1 Jul 2020 19:57:47 +0200 (CEST) Received: by mail-wm1-f50.google.com with SMTP id f139so24185434wmf.5 for ; Wed, 01 Jul 2020 10:57:47 -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=0VardhyX0rUhB5PFprzOrCB4tPv7Cggyl2hEmRZq4vo=; b=TLo58DuegTurKX7pLxsa+azqLAN26uy9XzCVwZuhn8Jn9ZmrIYH+bEi6aMcI9NuN2E 52g3CnOmDLP1BwMp4Qpt2FVMfjZojqIsg4/QWJOkMeMFIhZpcg3udxhwvKV4FGUS9rVH VyIoCFfCjt9LmAqq3l8t3ZAdBxMwVXz1v0CSp8b5lRJv5SLAFeuI4UMr4TMAs5dVG9cr htU2lKRnq0OQzWfIExja2pJcoyP9fMDqP6o7diAtyNiemldot65RhkDbtqHNhOCynlVX kxC4iTTBOXGJaeqle6/k3s3LvUbZ3PxXfYbP+z1Kkd6IZWQKyK9jLhnxCdvVbnT8hpMC UzXQ== 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=0VardhyX0rUhB5PFprzOrCB4tPv7Cggyl2hEmRZq4vo=; b=j/FXtaflq8ec6TsgmjQcT0emddb20aAV0VfbGEbgdNuKkYEyrytCM3iSDU2S7m6Ahi TiNmvNRrrU1AhkdiJgN2emQ3ufQ+lEVCzrdBUbW5Uq7X+3RfJGr3IeqCITICWandfyy5 LcYEZ1nUIqE5Ty+vhB444NLni2yuJPif7sDbmT+ALDqxv8qaoOje1WmG6+40O2ycppFL Pf4aMob13jI+o6zGBVk15tath0gl8STqMZDjnVCVuPC+D/gZI1WONLQLeHEk0Jhb4khV XksjmBtW9Voky/VAiEeyM1EiKgGNoZ+ME+s/LvkAXt0B5LojNtG2vUc8dj1UORHFDC1X StTw== X-Gm-Message-State: AOAM530fSF+Dd0F8oYSMB+zaEPLz3TxQ+fZvN0GLBoTYt7grXMZzPqM6 Fe3HvMdvsRiY8nx8cfUTYOiMUl7g3T9jQWUsKZI= X-Google-Smtp-Source: ABdhPJzvCShZN7jy0W7yQYzYwUQVoeif0VUH0THk/Onpu2UM6JdFWUXnucgyiotK6gV5TKoNF6orLoi2C1MCz6c7XRo= X-Received: by 2002:a1c:2157:: with SMTP id h84mr27137746wmh.35.1593626266969; Wed, 01 Jul 2020 10:57:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Cliff Burdick Date: Wed, 1 Jul 2020 10:57:35 -0700 Message-ID: To: David Aldrich Cc: Matt Laswell , 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" Another option is to use rte_pktmbuf_chain(), and chain the buffers together. That sounds more like what you were intending to do in the first place. If you do that, make sure your driver supports it (mlx5 does), and set the data/pkt_len appropriately for each part of the chain. This also is zero-copy. On Wed, Jul 1, 2020 at 9:48 AM David Aldrich wrote: > 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 > >> >>>> > >> >>> > >> > > >