[dpdk-users] Why is udp packet, sent by dpdk, received with zero'd payload?

Cliff Burdick shaklee3 at gmail.com
Wed Jul 1 17:38:53 CEST 2020


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 <david.aldrich.ntml at 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 <shaklee3 at 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. 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 at 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 | . at .....@...}..E.
>>> 00000010: 00 2B 00 00 00 00 40 11 F5 E8 C0 A8 01 69 C0 A8 | .+.... at ......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 <shaklee3 at gmail.com> 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 at 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
>>>>>
>>>>


More information about the users mailing list