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 56F69A0350 for ; Wed, 1 Jul 2020 17:39:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 398A91D447; Wed, 1 Jul 2020 17:39:06 +0200 (CEST) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by dpdk.org (Postfix) with ESMTP id 354621D446 for ; Wed, 1 Jul 2020 17:39:05 +0200 (CEST) Received: by mail-wr1-f43.google.com with SMTP id z2so2206771wrp.2 for ; Wed, 01 Jul 2020 08:39:05 -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=Dm05DUF71R4L+Mzshzymazgj5OhiqYE1U/5TpcoXA98=; b=j8oe1EFJ8JVnSnDG8c+3nWRhWInb5b1qr5K02hlCvfY80/AM1qfF2lXqgBzkhCJg85 nzXMgemoLe3b6hwECNUEHtrOdUQ9RMpIYjL2m9LNqoWDCEZZLER5fRXAbwTpxkh8QrzQ tvjVJ6z5RJCLepH+8/+y1RZbyFj14KUTZTDBIvLKGw3wg+makS/3HICcuH/HGT7jqVKQ tAvU2VJH81t/3h+4LYwP4yFxb2pKnnVgL+/3UBO9ORp6ekbknfZW/GVXDZKnl/6trvqM lEEYar9gipq/M5GFLbOYH//8uP6C4f+77Jy7PpnJ6gnU/lwkw7daBVvHd/hsepCjgcA/ SOXA== 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=Dm05DUF71R4L+Mzshzymazgj5OhiqYE1U/5TpcoXA98=; b=GyqS7ZT2sb9+EDevudVKOwUU72J57MbwQsuv7gV871tMxyGhMllZiLIyTnvyEikJIz qa8A2KLcTd8yeU2OOmNkaeHi6CVQ5I2IIqtsKNEkb1HB/DCmlN8f29apYF70b8CcJ7jO PfZqVNd2ox1QKoji/Ew5yam6NpBg0TkIAtZuzBL/URszmZzgEi2siGzlp7vqonSEukAw Ey9s/CI0ClhUT/rDDLhsSa1wrBxtJdcl60U4bQ/05q2PMlmCbKvA17Ll3ELY9SeJMPyC TE2KhwWk2DlfluKYl+tz94eNQGJWIyv9/fYXnbdpoHfdgoyuLMiYQO8cmyO51aR8rIwR /bRA== X-Gm-Message-State: AOAM5314kd/w26HdxUKE6iCw06xslhkE+IOgrd2evCrNebjGFkBMG61c xGvLCdXpresLj4uAz6tLavwVPhgZ3+U+BiJMZDw= X-Google-Smtp-Source: ABdhPJzoBL5KAO1WZOyTBTMH/9InsyGTzdi8FAfTxaSWrWT6x/FfoQVWtXTUoNA1lZFOqFr7nQGuc7UcH7r4bExn8zU= X-Received: by 2002:a5d:5310:: with SMTP id e16mr26062926wrv.289.1593617944781; Wed, 01 Jul 2020 08:39:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Cliff Burdick Date: Wed, 1 Jul 2020 08:38:53 -0700 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" How are you setting up ptMbuf before you call those? It seems that if you had a payload beyond the UDP header you would need to set those appropriately in the data/pkt_len fields prior to those calls. On Wed, Jul 1, 2020 at 8:06 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 >>>>> >>>>