0
votes

I'm doing this project, where I have to send a bunch of packets (using rte_eth_tx_burst) ,from one network card, to another network card. these 2 network cards are linked(by Fiber I guess? it was not me who linked them.), so if I just use tcpdump to listen to the other network card, I can capture the whole thing, and store them into a pcap file.

My test environment: 1.a Linux machine, with 2 pairs of linked network cards: eth1 and eth2 are linked, eth3 and eth4 are linked also. 2.my program, listens to eth1. 3.I send a pcap file using eth2 (cmd: tcpreplay -i eth2 test.pcap) 4.my program gets the packet stream, frame by frame, for every frame it recieves, it sends it out, from eth3, using rte_eth_tx_burst() provided by dpdk. 5.I run tcpdump to listen to eth4(cmd:tcpdump -i eth4 -w recieve.pcap -B 1000)

My current problem is: 1. the frames are not in their original orders. (but the contents are the same.) 2. the time gap between frames are not the original gaps.(but I guess this is inevitable). result file compared to the original file

question: 1.does dpdk guarantees the send order for packets you put in the send queue. 2.perhaps it's because that tcpdump doesn't guarantee the order? 3.or is this problem unsolvable?

1

1 Answers

2
votes

Yes, the order of packets send by tx_burst should be guaranteed, provided you're just using one queue.

The out of place packet you are seeing is a reply from eth4, as tcpdump also records outgoing traffic. Remember that the TCP stack is still working as usual on eth4.

Why not use DPDK to capture the packets too? It'd be more reliable and you'd only see incoming packets. Theres an utility for that: pdump. Or you can choose only incoming direction in tcpdump using -Q in.

Also, maybe you already know this, but there's an example app bundled with DPDK that does exactly what you're trying to do: L2FWD.