Clarification about the helloworld setup

Hi! I am running eRPC on a lab testbed where 2 servers are connected to a single Tofino switch: A <---> Switch <---> B. Both servers have the same setup below and I could compile eRPC with cmake . -DPERF=OFF -DTRANSPORT=dpdk; make -j16; successfully.

Operating system: 18.04.6 LTS (Bionic Beaver)
NIC model: Mellanox Technologies MT27710 Family [ConnectX-4 Lx]
DPDK version: 19.11.5
rdma_core: compiled from source

The switch does nothing but forwards traffic from A to B and B to A and I have made sure that A and B could ping each other via local IPs of the ConnectX-4 Lx NIC, say 10.1.1.3/24 is assigned to A's NIC port and 10.1.1.6/24 to B's NIC port.

I modified common.h for both servers before make dpdk and run the binary.

static const std::string kServerHostname = "10.1.1.6";
static const std::string kClientHostname = "10.1.1.3";

Here is what I got from the two terminals where A is the client and B is the server.

On A (client):

lc@A:~/eRPC/hello_world$ sudo ./client
93:867973 WARNG: eRPC Nexus: Testing enabled. Perf will be low.
94:384660 WARNG: Running as primary DPDK process. eRPC DPDK daemon is not running.
94:907292 WARNG: DpdkTransport created for Rpc ID 0, queue 0, datapath UDP port 10000
27:102604 WARNG: Rpc 0 stuck in rte_eth_tx_burst

On B (server):

lc@B:~/eRPC/hello_world$ sudo ./server
82:977299 WARNG: eRPC Nexus: Testing enabled. Perf will be low.
83:498125 WARNG: Running as primary DPDK process. eRPC DPDK daemon is not running.
84:028962 WARNG: DpdkTransport created for Rpc ID 0, queue 0, datapath UDP port 10000

I have also tried to debug with tshark packet capture for the NIC port of A and B, and here is what I got:

# For A's port
1 0.000000000     10.1.1.3 → 10.1.1.6     UDP 434 58233 → 31850 Len=392
2 0.000347489     10.1.1.6 → 10.1.1.3     DCERPC 434 Request: seq: 0 opnum: 0 len: 0 

# For B's port
3 51.443545937     10.1.1.3 → 10.1.1.6     UDP 434 58233 → 31850 Len=392
4 51.443739751     10.1.1.6 → 10.1.1.3     DCERPC 434 Request: seq: 0 opnum: 0 len: 0 2e312e33-0000-0000-0000-000000000000 V0

It seems that the client A was able to successfully send the first packet to B (1 & 3), and B did respond with a packet (4) and got received by A (2), but then nothing happens until the warning Rpc 0 stuck in rte_eth_tx_burst appears.

It would be really helpful if there is any clarification about whether the setup aligns with the usage of hello world. Thanks!

erpc-io / eRPC

Clarification about the helloworld setup #96