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
