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 | [email protected].. 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 <[email protected]> wrote: > Are you setting data_len and packet_len in the mbuf before sending? > > > On Wed, Jul 1, 2020, 03:23 David Aldrich <[email protected]> > 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 >> >
