-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
can't use pktgen to send udp traffic to public server from local VM / public server #6
Comments
I setup dpdk enviroment in public server1 to send packet to public server2 (not connected via ethernet, but possible to send udp packets,right?) I tried starting pktgen in sending mode in server and it was saying :
I tried to set the receiving ip from main.c and sending ip+mac from the config.ini (DPDK bound mac and IP) but no improvements. what possible wrong thing can I be doing here you think?
I have set receiving ip in main.c too by
|
Hello Fuji,
I can confirm that the sender is failing to send packets, otherwise you would see stats being printed periodically on the console. What network card are you using? What is your DPDK (not UDPDK) configuration? Have you ever sent data with DPDK from that host? By the way, you said that you could see the outbound packets in tcpdump; did you use dpdk-pdump or similar? As for the non-IP received packets you see in the logs, they are STP and ARP ("broadcast ARP Who has 149.20.187.151? Tell 149.20.187.145") coming from other hosts in the network, so you can ignore them. |
I am totally new to DPDK. I just learned 1 days ago that to fulfill my actual purpose I have to use Open vSwitch in the same server running dpdk. I actually tried UDPDk in local VM.. And tried to send packets from VM1(using UDPDK) to VM2, both VM were confugure with NAT and they using vfio driver. I didn't usw pdump to catch packets, can you shed some light on that? And isn't it possible to send dpdk packets from 1 local vm to another local vm using ether net address? |
As far as I know, tcpdump doesn't work with DPDK because DPDK takes full control of the NIC whereas tcpdump reads from the regular network stack. You can learn more about pdump here: https://doc.dpdk.org/guides-16.07/sample_app_ug/pdump.html
It depends. If there is just a switch in-between, that should be possible. If you have routers (layer 3 devices) in the middle, the lack of ARP support may represent an obstacle unless you set a static ARP table. |
yeah I will try to use Open vSwitch to integrate with dpdk to send/receive data first, then I will look into integrating UDPDK with Open vSwitch and report back. So if I use pure dpdk with open vSwitch then I have to do some extra work to make it possible for UDP packet sending right that you have already done in UDPDK? And thanks for the help..! |
lats update : I was able to send udp packets using apps/pktgen from VM1 (using UDPDK) to Another VM2 (normal) and confirmed by receiving UDP packets from java app, and I used qemu/kvm and my vm's network were configured via NAT, actually they were connected through virtual ethernet cable which we confirmed by "arping" each-other. Same went successful for 2 public server but they were connected in same switch (confirmed via 'arping' each other). I think that's it for UDPDK as to send 1 public server to another remote public server, we have to use Open vSwitch. |
@leoll2 , I was able to send UDP packets even to remote server by setting target mac as gateway (next hop) and target ip as destination ip and I can receive those udp packets from that remote public server. Now I can't receive udp packets using pktgen, it seems like the code is stuck in "udpdk_recvfrom()" function and isn't proceeding. And another thing, whenever I run pkgen recv/send mode for the first few seconds, it seems to poll some large amount of non ipv4 packets everytime though I am not sending anything. can you shed on light what could be the possible reason for the code to stuck in udpdk_recvfrom() function? |
Hard to tell, what I can suggest is to instrument the source code of udpdk_recv with some log lines, then recompile. Even if you're not familiar with UDPDK architecture, there are quite a few comments in the code.
They are just packets coming from other hosts/devices in the network, not necessarily targeted to your host/application. If you are curious, you can inspect their content using this tool. Anyway they are ignored, so don't worry too much.
May I ask you more details on how you configured UDPDK and (possibly) the devices in the middle? It could be helpful for other people trying to solve the same problem. If I understand correctly, you configured the sender with destination |
Sending is working properly currently. |
from pktgen related question (stackoverflow) I came to know that the way I sent the packets is not a standard way and I will have to create tap/tun interface to send receive dpdk accelarated packets from/to another public server. So when I will send a dpdk accelarated udp packets to another public server then it will also help the neighbour nodes to resolve dpdk-binded ip which will help in receiving udp packets destined for dpdk-binded ip. I am not very clear about using tap/tun interface and use that to send receive packets, can you suggest how to implement that with your UDPDK for sending/receiving? |
we setup the full dpdk environment in VM. then changed the config.ini a bit by changing the "port0" mac & ip to dpdk binded ethernet address and ip assigned to that interface. Then in main.c, I changed the recv_ip to my public server ip. I started the pktgen after make, I am seeing those "vm_dpdk_ip > public_server_ip" packets from host pc through tcpdump command but I am not actually getting those udp packets in the server (checked via tcpdump). The server is just simple linux server which was meant to receive packets and my VM's dpdk binded ip was meant to sent. my main target was to check whether I am able send/receive udp packets using dpdk in public internet. What am I doing wrong here ? Thanks in advance
The text was updated successfully, but these errors were encountered: