Help performing PDP with DPDK

[mechaniputer]

Hello. I am trying to write a DPDK-based tool to test the performance of a single FastDDS host. That is, the DPDK-based tool will run on a second machine and pretend to be another instance of FastDDS, and gauge the latency and throughput of the single actual FastDDS application over the network.

I am having trouble getting the initial handshake to succeed. I am sending a packet from the DPDK side which contains participant information from a wireshark trace that I collected earlier from the round-trip FastDDS setup that I am trying to emulate. This is the first step of the PDP described in [1]. Both machines are set up with a static IP and are directly physically connected. This is the same configuration from which I collected a wireshark trace of a successful PDP to work from.

Wireshark shows that my DPDK-generated packets parse correctly on the FastDDS machine as RTPS and contain the same information (aside from updated timestamps) as the ones from my earlier trace. However the FastDDS host is not replying like it did in my original wireshark trace. In my understanding it is supposed to reply with an updated unicast version of the participant advertisement packet once it receives the participant advertisement packet from the DPDK side. However all I see coming from the FastDDS app is the repeated (10 Hz) initial packet, with similar content to the one from the DPDK side that FastDDS is not responding to.

Could anyone shed any more light on the connection process and what my packets should look like in order to get FastDDS to complete the participant discovery phase? What are the critical parameters to at least get through the PDP and start exchanging traffic for a performance test? (especially, which parameters other than the timestamp fields need to be updated and thus cannot simply be replayed from a trace of a successful PDP?).

Thank you!

[1] https://fast-dds.docs.eprosima.com/en/latest/fastdds/discovery/discovery.html#discovery-phases

[paxifaer]

If you want to test latency and throughput, you don't have to use DPDK. You can use the code in the Fast-DDS/test folder. In addition, PDP service discovery is participant-level service discovery, which generally uses a multicast mechanism and has built-in endpoint listening packet discovery. Please confirm whether the multicast address is correct.

[mechaniputer]

For reasons that would only complicate this thread, I must use DPDK and cannot use the code from Fast-DDS/test. Using DPDK to establish communication with a FastDDS host is my goal. This is one step in a longer task involving DPDK and I have no other choice.

The multicast (destination) IP addresses match between the packets sent by the DPDK and FastDDS hosts. Can you suggest any other parameters I should check?

I have also been trying to log whether my DPDK messages are even being seen by the FastDDS library, so suggestions regarding that are also appreciated. I am hoping to determine why the initial announcements are being ignored by instrumenting the FastDDS library itself, since I can't find any other ways to approach this.

[paxifaer]

It is difficult to build connection with FASTDDS by directly using DPDK. Maybe you can crete some simple pub/sub code by use fastddsgen.To be honest ,I cannot figure it out why you use DPDK,may you show me your code?

[Mario-DL]

Hi @mechaniputer,

Thanks for being interested in Fast DDS and thanks also to @paxifaer for taking part in.

Completing a successful simple discovery phase exchanging raw datagrams is perhaps a harsh way of measuring the intended performance. Instead, it would be easier to create a complementary publication/subscription applications in server and client to measure the round-trip time.

Anyways, I will give you a couple of hints for the discovery phase:

• Use initialpeers as both hosts are directly wire-connected to each other.
• In the PDP datagram, specify where participants are listening for discovery phase traffic (the metatraffic unicast locators)
• Ensure that participant GUIDPrefixes are different and Entity_ids are the one for the participant.
• After PDP, participants exchange information about their endpoints in the EDP simple discovery phase

As you can see, many details should be taken into consideration.
Fast DDS has a performance test suite that you could also investigate.

You may reach our team for further support if required at [email protected] or by phone at +34 91 804 34 48.

[mechaniputer]

Thank you for these hints. I had already created a normal FastDDS round trip app as the first step of my project, and it worked. That is how I obtained a trace to try to imitate with DPDK. However, as stated previously, my goal is to complete PDP with DPDK. I cannot choose a different approach because my goals specifically relate to using DPDK.

I am still having difficulty getting FastDDS to respond to the initial announcement packet from DPDK, and cannot find anything that I have omitted.

I am worried that the "vendor-specific" submessage may be the problem. Also, I am not sure why, but wireshark thinks that the checksums generated by normal FastDDS are incorrect (but the checksums generated by my DPDK code appear to be correct).

Can you tell me what part of the library examines the received PDP packets? I want to add some printouts to see why my packets are being ignored/rejected by the FastDDS library.

[mechaniputer]

I got it to respond. Finally seeing the expected ACKNACKS, etc. There was a checksum problem in my DPDK code. Now that I'm getting expected results, I probably have it from here. Thanks again for the hints.

[mechaniputer]

I think I still need help with this. I am generating all of the handshake packets correctly as far as I can tell, and FastDDS is receiving them and responds, but never actually sends the DATA(w) or DATA(r).

In my traces of a normal round trip FastDDS application between my two machines, the client side only has to send the announcement packet and 3 heartbeat packets (for builtin pub, sub, and participant) before the server responds with DATA(r) and DATA(w).

I modified my DPDK client to only send those aforementioned packets in a loop and collected a Wireshark trace, which is attached (I had to put it into a ZIP archive due to upload file type restrictions). I have studied the fields in my generated messages in great detail and cannot find a problem. Perhaps someone else can. I would be eternally grateful.
Failed_DPDK_handshake_9_15_2024.pcapng.zip

In the Wireshark trace, 10.0.0.2 is the DPDK client, and 10.0.0.1 is the FastDDS server. My question is, why doesn't the server send the builtin reader and writer packets with DATA(r) and DATA(w) submessages?

Also, why is the FastDDS server sending preemptive ACKNACKs? In my successful non-DPDK trace, FastDDS did not do this.

[paxifaer]

From your description, I guess you are using DPDK to simulate the sub/pub side of DDS for communication. This is more difficult. You need to send simulated PDP and EDP data packets to prompt both parties to complete PDP and EDP service discovery respectively. it's difficult