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 B4A18A0350 for ; Wed, 1 Jul 2020 17:56:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 130A61D517; Wed, 1 Jul 2020 17:56:55 +0200 (CEST) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by dpdk.org (Postfix) with ESMTP id 44E4E1D515 for ; Wed, 1 Jul 2020 17:56:53 +0200 (CEST) Received: by mail-vs1-f45.google.com with SMTP id u133so42566vsc.0 for ; Wed, 01 Jul 2020 08:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinite-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BPbPTYpXFL0Cmj0J4SzW+nPvXYGN2+jROkK/QMQiiFs=; b=NIjL0Wgfr+5elqqztrifWFZD189+1eSuF2wIyXyB5jYUOM51ZaY2pQPeIxG14t3v1E lBQqxOTjO5XXmCTJEnwGgReb9rS5Q6BDzLUz58Q0e0vQNeRDy4O/3YN8uQEhRpj0WPO0 YkOJ4v1N+TVm62sYLejqAJXQmNAPZKJjbaNmqUQRKK2rr+Lcl5E1VgnrB8xuUapYdOk4 eVIvaBxDkXEVrWwgepI/PJyWDrBrfzrPKJBCJ+fGku2tvDxabi/OR0Wl+jgb/XXjNWel Nhb4fjLbU9phs6B18qz6N2debBv43XGChxUlOADOOtUW13a/zQxqAJR4dGvIPzmVZe9N YElg== 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=BPbPTYpXFL0Cmj0J4SzW+nPvXYGN2+jROkK/QMQiiFs=; b=o0zmSooGYsYOHVd7pbNsssVjhwS77NPgMSQLfCjUMJKe4O9343wX223dYnTrkDr4fB HYqT4IIV+eRdTzKObqFly9x52ODhuNUjRWTFh7O8j/IJUxnRi325po9Z7RamcoVSIOFl GgnY8m/drREwkqYVOGngAgF70bWBJEP1RNzI71pJwBy/qBgDdpl9HcJm9lOEYKzY5iq3 U/6DiGvDHaxLKa8llY9Qphl6Ht1Sx0PG0OEjgoWYVbV5+N1kibSj4HcDD8/YdagF5zLu 3iChedFZB5mimYc6+GuPQwWRSVqvQLXAEnR+OEF7zs5/YIFSdD1Hmy4DsbEFoV+2lxs0 u5vQ== X-Gm-Message-State: AOAM5320DHnKq7PU26xeTYD6jmVIaQQdUXQmMJmh4JnEO1N/zium5uPG HITXqRzKxswuvMrfYArVgi+r3jQ3fa5LyvMv6VOZgw== X-Google-Smtp-Source: ABdhPJzGjn1WdwKORD7tHx5S3uC9jmvHVGPd0DcovDbNDrGiF8+uMgxaqJkn9JUBL+gZE/NcvaW3lDIVkoPTHCX7oFM= X-Received: by 2002:a67:f454:: with SMTP id r20mr17941241vsn.20.1593619012347; Wed, 01 Jul 2020 08:56:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matt Laswell Date: Wed, 1 Jul 2020 10:56:41 -0500 Message-ID: To: David Aldrich 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" 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 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 > > >>> 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 > >>>> > >>> >