[dpdk-users] Sent a UDP packet, but length is wrong when captured
dohyung.kim at fluidic.io
Thu Sep 27 18:24:36 CEST 2018
I tried AF_PACKET PMD instead of libpcap-based one, and it works as
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.
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.
> On 2018년 09월 27일 03:28, DoHyung Kim wrote:
>> I'm new to DPDK and having trouble in crafting TX packets.
>> My application receives and caches UDP packets after dropping header
>> 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
More information about the users