[dpdk-users] Sent a UDP packet, but length is wrong when captured

[dpdk-users] Sent a UDP packet, but length is wrong when captured

[DoHyung Kim]

Hi,

I'm new to DPDK and having trouble in crafting TX packets.

My application receives and caches UDP packets after dropping header part.
When clients request, it sends the cached packets after prepending them 
a new header mbuf
(by chaining), which contains all the headers to UDP's filled correctly 
for targeting the clients.
Though I think I'm doing nothing wrong, I see the transmitted ethernet 
frames are
14 bytes longer than expected.

Please see a capture of such a packet from Wireshark below:





The multi-seg mbuf is 1370 byte long, but weirdly enough, its 1384 when 
captured back.
I'm using libpcap based vdev on loopback interface for testing. And DPDK 
version is 17.11.3 on Ubuntu 18.04.

Any clue?

Thanks in advance.

DoHyung Kim

Re: [dpdk-users] Sent a UDP packet, but length is wrong when captured

[DoHyung Kim]

I did some more experiments.

One thing very weird is if I transmit the newly prepended header part 
only, then it is sent out correctly. But the cached part has the 
additional 14 bytes (I guess only 10 bytes addition since Ethernet 
frame's CRC is shown due to verification error) when sent alone. The 
very packet is as received from the PMD only with its ethernet/ip/udp 
headers are stripped off using rte_pktmbuf_adj.

So I guess my problem is not exactly relevant to multi-seg mbuf.

Any clue will be appreciated.

I can copy the cached packet into a new packet after the newly formed 
headers. But I hope to avoid memory copies as much as possible.

Thanks.

DoHyung

On 2018년 09월 27일 03:28, DoHyung Kim wrote:
> Hi,
>
> I'm new to DPDK and having trouble in crafting TX packets.
>
> My application receives and caches UDP packets after dropping header part.
> When clients request, it sends the cached packets after prepending 
> them a new header mbuf
> (by chaining), which contains all the headers to UDP's filled 
> correctly for targeting the clients.
> Though I think I'm doing nothing wrong, I see the transmitted ethernet 
> frames are
> 14 bytes longer than expected.
>
> Please see a capture of such a packet from Wireshark below:
>
>
>
>
>
> The multi-seg mbuf is 1370 byte long, but weirdly enough, its 1384 
> when captured back.
> I'm using libpcap based vdev on loopback interface for testing. And 
> DPDK version is 17.11.3 on Ubuntu 18.04.
>
> Any clue?
>
> Thanks in advance.
>
> DoHyung Kim

Re: [dpdk-users] Sent a UDP packet, but length is wrong when captured

[DoHyung Kim]

FYI,

I tried AF_PACKET PMD instead of libpcap-based one, and it works as 
expected.

Reading the source code, PCAP PMD's TX function is really simple and 
doesn't seem doing something wrong. So I guess it's a problem with libpcap.

If anyone sees no obvious problem in his/her TX code and libpcap PMD 
works weird, I think it's a good idea to switch to AF_PACKET PMD. The 
only caveat here is it's not well-documented. I had to consult its 
source code to configure it properly.

DoHyung

On 2018년 09월 27일 10:54, DoHyung Kim wrote:
>
> I did some more experiments.
>
> One thing very weird is if I transmit the newly prepended header part 
> only, then it is sent out correctly. But the cached part has the 
> additional 14 bytes (I guess only 10 bytes addition since Ethernet 
> frame's CRC is shown due to verification error) when sent alone. The 
> very packet is as received from the PMD only with its ethernet/ip/udp 
> headers are stripped off using rte_pktmbuf_adj.
>
> So I guess my problem is not exactly relevant to multi-seg mbuf.
>
> Any clue will be appreciated.
>
> I can copy the cached packet into a new packet after the newly formed 
> headers. But I hope to avoid memory copies as much as possible.
>
> Thanks.
>
> DoHyung
>
> On 2018년 09월 27일 03:28, DoHyung Kim wrote:
>> Hi,
>>
>> I'm new to DPDK and having trouble in crafting TX packets.
>>
>> My application receives and caches UDP packets after dropping header 
>> part.
>> When clients request, it sends the cached packets after prepending 
>> them a new header mbuf
>> (by chaining), which contains all the headers to UDP's filled 
>> correctly for targeting the clients.
>> Though I think I'm doing nothing wrong, I see the transmitted 
>> ethernet frames are
>> 14 bytes longer than expected.
>>
>> Please see a capture of such a packet from Wireshark below:
>>
>>
>>
>>
>>
>> The multi-seg mbuf is 1370 byte long, but weirdly enough, its 1384 
>> when captured back.
>> I'm using libpcap based vdev on loopback interface for testing. And 
>> DPDK version is 17.11.3 on Ubuntu 18.04.
>>
>> Any clue?
>>
>> Thanks in advance.
>>
>> DoHyung Kim
>