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
