Reputation: 31
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).
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?
Upvotes: 0
Views: 1046
Reputation: 180
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.
Upvotes: 2