On Thu, 24 Jul 2025, Gokul K R (MS/ETA7-ETAS) wrote: > Hi, > > In the meantime, I was able to successfully replay my PCAP file using the dpdk-burst-replay tool from your repository (https://github.com/FraudBuster/dpdk-burst-replay). Below is the output from the tool: > > sudo ./src/dpdk-replay wendutput.pcap 0000:01:00.0 > preloading wendutput.pcap file (of size: 5900 bytes) > file read at 100.00% > read 100 pkts (for a total of 5900 bytes). max packet length = 43 bytes. > -> Needed MBUF size: 174 > -> Needed number of MBUFS: 100 > -> Needed Memory = 16.992 Mo > -> Needed Hugepages of 1 Go = 1 > -> Needed CPUs: 1 > -> Create mempool of 100 mbufs of 174 octs. > -> Will cache 100 pkts on 1 caches. > file read at 100.00% > -> NIC port 0 ready. > > RESULTS : > [thread 00]: 1.703287 Gbit/s, 3874767.513949 pps on 0.000026 sec (0 pkts dropped) > TOTAL : 1.703 Gbit/s. 3874767.514 pps. > Total dropped: 0/100 packets (0.000000%) > Cannot close started device (port 0) > I have a question: > > #1: The tool shows that packets are transmitted, but they are not received on the other end. The same setup works fine with the testpmd application. Since the transmit-side NIC is bound to DPDK, I cannot use tools like Wireshark or tcpdump to verify transmission. Is there any recommended way to confirm whether packets are actually being sent from the DPDK-bound NIC? Once again, are you sure destination MAC addresses in the replayed packets match that of the receiver NIC? Have you enabled promiscuous mode on the receiver? Thank you. > > In parallel, as per your suggestion, I’m also exploring the DPDK PCAP PMD to replay my PCAP file. > > > Mit freundlichen Grüßen / Best regards > > K R Gokul > > Compact Devices, ESxx, Product and System Acceptance Tests (MS/ETA7-ETAS) > Robert Bosch GmbH | Postfach 10 60 50 | 70049 Stuttgart | GERMANY | http://www.bosch.com/ > Mobile +91-9003755978 | KR.Gokul@in.bosch.com > > Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 14000; > Chairman of the Supervisory Board: Prof. Dr. Stefan Asenkerschbaumer; > Managing Directors: Dr. Stefan Hartung, Dr. Christian Fischer, Dr. Markus Forschner, > Stefan Grosch, Dr. Markus Heyn, Dr. Frank Meyer, Katja von Raven, Dr. Tanja Rückert > > -----Original Message----- > From: Ivan Malov > Sent: Thursday, July 24, 2025 3:55 PM > To: Gokul K R (MS/ETA7-ETAS) > Cc: users@dpdk.org; dev@dpdk.org; Nivethitha N Shanmugasundaram (ETAS-ICA/XPC-Fe6) ; Aloysius Nishanth Britto (MS/ETA7-ETAS) > Subject: RE: Issue with DPDK-Burst Replay – No Frame Transmission Observed Despite Successful Replay > > Hi, > > On Thu, 24 Jul 2025, Gokul K R (MS/ETA7-ETAS) wrote: > >> Hi Ivan, >> >> I hope you're doing well. >> >> Point #1: >> Since the DPDK-Burst Replay tool is not an official part of the DPDK project and is community-developed, could you please let us know whom we should contact for support or further information regarding this tool? > > For the very same reason (not an in-house tool), I have no way of knowing. > Perhaps take a look at repository owner's profile on GitHub or something. > >> >> Point #2: >> We have identified an issue while using dpdk-burst replay tool. >> During EAL mempool initialization, “--pci-whitelist” parameter is given as an argument for “rte_eal_init” function. However, when rte_eal_init is executed with these arguments, it fails with the following error: >> >> ./dpdk-replay: unrecognized option ‘--pci-whitelist’ >> Invalid command line argument >> >> We couldn’t find any official documentation on the --pci-whitelist parameter. Could you help clarify its purpose and whether this argument is essential for the tool to operate correctly? > > 1) In 2020, commit db27370b5720 ("eal: replace blacklist/whitelist options") > renamed this argument. Now it is '-a' ('--allow') and '-b' ('--block') [1]. > 2) The argument is application-agnostic and is designed to give a finer control > on which devices get picked by DPDK during EAL initialisation. > 3) Whether the argument is needed for the use of this particular application > is not apparent to me. One should refer to the application's documentation. > >> >> Point #3: >> Could you also suggest any official DPDK tool that supports replaying PCAP files? This would help us explore alternatives that are actively maintained by the DPDK community. > > Please take a look at DPDK pcap PMD [2]. It may meet your needs. > > [1] https://doc.dpdk.org/guides-25.07/linux_gsg/linux_eal_parameters.html#device-related-options > [2] https://doc.dpdk.org/guides-25.07/nics/pcap_ring.html > > Thank you. > >> >> Looking forward to your inputs. >> >> Best regards, >> Gokul K R >> -----Original Message----- >> From: Ivan Malov >> Sent: Wednesday, July 23, 2025 11:43 AM >> To: Gokul K R (MS/ETA7-ETAS) >> Cc: users@dpdk.org; dev@dpdk.org; Nivethitha N Shanmugasundaram >> (ETAS-ICA/XPC-Fe6) >> Subject: RE: Issue with DPDK-Burst Replay – No Frame Transmission >> Observed Despite Successful Replay >> >> On Wed, 23 Jul 2025, Ivan Malov wrote: >> >>> Hi, >>> >>> On Wed, 23 Jul 2025, Gokul K R (MS/ETA7-ETAS) wrote: >>> >>>> Hi Ivan Malov 😊 >>>> >>>> Use Case: >>>> I'm currently using the DPDK-Burst-Replay tool to replay captured >>>> PCAP files at specific data rates (e.g., 150–200 Mbps). >>>> >>>> Response to your feedback: >>>> Point 1: "Port 0 is not on the good NUMA ID (-1)" >>>> I’m aware that this message is printed due to the NUMA ID being >>>> returned as -1. >>>> I've just started diving into the source code and found that the >>>> call to >>>> rte_eth_dev_socket_id() returns -1, which typically indicates an error. >>> >>> No, -1 typically translates to 'SOCKET_ID_ANY'. In order to rule out 'EINVAL' >>> in 'rte_errno', one should attempt to invoke 'rte_eth_dev_socket_id' >>> within the loop of 'RTE_ETH_FOREACH_DEV' (see examples in DPDK) and >>> print the socket ID. >>> >>>> However, the current implementation does not output the rte_errno, >>>> which could help identify the root cause. I'm working on modifying >>>> the code to print the error code for better debugging. >>>> >>>> Point 2: "NIC Link is UP" >>>> Yes, on the NIC side, the link is up. I'm also able to transmit >>>> packets successfully using the testpmd application. >>>> >>>> Question: >>>> Could you please confirm if the current version of the >>>> DPDK-Burst-Replay tool supports replaying Ethernet frames larger >>>> than >>>> 64 bytes (e.g., up to >>>> 1500 bytes)? Or has the tool been enhanced to support this use case? >>> >>> The tool seems like an external application. Try to look for any >>> mentions of API 'rte_eth_dev_set_mtu' or just the term 'mtu' in that >>> source code. If there are no such mentions, then default MTU applies, >>> which depends on the driver. >>> >>> Have you tried querying statistics to find the cause of the drops? >> >> Also, given the fact that the application replays some pcap traffic, have you made sure the receiver (where you seek to watch the replayed traffic arrive) has got 'promiscuous' mode [1] enabled? IIRC, 'test-pmd' enables it by default. >> >> [1] >> https://doc/. >> dpdk.org%2Fapi-25.07%2Frte__ethdev_8h.html%23a5dd1dedaa45f05c72bcc3549 >> 5e441e91&data=05%7C02%7CKR.Gokul%40in.bosch.com%7Cb670bffe53b8485c75a9 >> 08ddca9c56bf%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638889495040 >> 750455%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA >> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda >> ta=7xqux5VPYgMerNkhy7YOCzj371irrkhEFFrkHTuK1pg%3D&reserved=0 >> >> Thank you. >> >>> >>> Thank you. >>> >>>> >>>> Thanks for your time and support! >>>> >>>> Best regards, >>>> Gokul K.R >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Ivan Malov >>>> Sent: Friday, July 18, 2025 5:29 PM >>>> To: Gokul K R (MS/ETA7-ETAS) >>>> Cc: users@dpdk.org; dev@dpdk.org >>>> Subject: Re: Issue with DPDK-Burst Replay – No Frame Transmission >>>> Observed Despite Successful Replay >>>> >>>> Hi, >>>> >>>> (please see below) >>>> >>>> On Fri, 18 Jul 2025, Gokul K R (MS/ETA7-ETAS) wrote: >>>> >>>>> >>>>> Hi Team, >>>>> >>>>> I’m currently working with the dpdk-burst-replay tool and >>>>> encountered an issue during execution. Below are the details: >>>>> >>>>> >>>>> ___________________________________________________________________ >>>>> _ >>>>> __ >>>>> ___________________________________________________________________ >>>>> _ __ ______________________________________________ >>>>> >>>>> >>>>> Observation: >>>>> During replay, we received the following informational message: >>>>> >>>>> port 0 is not on the good numa id (-1) >>>> >>>> Which API was used to check this? Was API [1] used? If not, what >>>> does it show in the absence of 'numactl' command? >>>> >>>> [1] >>>> https://doc/ >>>> .dpdk.org%2Fapi-25.03%2Frte__ethdev_8h.html%23ad032e25f712e6ffeb0c19 >>>> e >>>> ab1ec1fd2e&data=05%7C02%7CKR.Gokul%40in.bosch.com%7C53a20884cad14b94 >>>> 7 >>>> a0008ddc9aff5bf%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C6388884 >>>> 7 >>>> 9792834143%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL >>>> j >>>> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C >>>> % >>>> 7C&sdata=XxPfmsX4WsR83ifUfkkup2jIOw4PU%2FX%2BdefEqVfazj4%3D&reserved >>>> = >>>> 0 >>>> >>>>> >>>>> As per the DPDK mailing list discussions, this warning is typically >>>>> benign—often seen on NICs like Intel I225/I210, which do not report >>>>> NUMA affinity. Hence, we proceeded with execution. >>>>> >>>>> >>>>> ___________________________________________________________________ >>>>> _ >>>>> __ >>>>> ___________________________________________________________________ >>>>> _ __ ______________________________________________ >>>>> >>>>> >>>>> Command Used: >>>>> >>>>> sudo numactl --cpunodebind=0 --membind=0 ./src/dpdk-replay >>>>> Original_MAC.pcap 0000:01:00.1 >>>>> >>>>> Execution Output: >>>>> >>>>> preloading Original_MAC.pcap file (of size: 143959 bytes) >>>>> >>>>> file read at 100.00% >>>>> >>>>> read 675 pkts (for a total of 143959 bytes). max packet length = >>>>> 1518 bytes. >>>>> >>>>> -> Needed MBUF size: 1648 >>>>> >>>>> -> Needed number of MBUFs: 675 >>>>> >>>>> -> Needed Memory = 1.061 MB >>>>> >>>>> -> Needed Hugepages of 1 GB = 1 >>>>> >>>>> -> Needed CPUs: 1 >>>>> >>>>> -> Create mempool of 675 mbufs of 1648 octets. >>>>> >>>>> -> Will cache 675 pkts on 1 caches. >>>> >>>> What does this 'cache' stand for? Does it refer to the mempool >>>> per-lcore cache? >>>> If so, please note that, according to API [2] documentation, cache >>>> size "must be lower or equal to RTE_MEMPOOL_CACHE_MAX_SIZE and n / >>>> 1.5", where 'n' stands for the number of mbufs. Also, documentation >>>> says it is advised to choose cache_size to have "n modulo cache_size >>>> == 0". Does your code meet these requirements? >>>> >>>> By the looks of it, it doesn't (cache_size = n = 675). Consider to >>>> double-check. >>>> >>>> [2] >>>> https://doc/ >>>> .dpdk.org%2Fapi-25.03%2Frte__mempool_8h.html%23a0b64d611bc140a4d2a0c >>>> 9 >>>> 4911580efd5&data=05%7C02%7CKR.Gokul%40in.bosch.com%7C53a20884cad14b9 >>>> 4 >>>> 7a0008ddc9aff5bf%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638888 >>>> 4 >>>> 79792843977%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw >>>> L >>>> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7 >>>> C >>>> %7C&sdata=VLPTrAXqY2FNmhA6mwLFEZgc6f4LFc7oa%2BUb8DrmtWs%3D&reserved= >>>> 0 >>>> >>>>> >>>>> >>>>> ___________________________________________________________________ >>>>> _ >>>>> __ >>>>> ___________________________________________________________________ >>>>> _ __ ______________________________________________ >>>>> >>>>> >>>>> Issue: >>>>> Despite successful parsing of the pcap file and proper >>>>> initialization, no frames were transmitted or received on either >>>>> the sender or receiver sides. >>>> >>>> Is this observation based solely on watching APIs [3] and [4] return >>>> 0 all the time? If yes, one can consider to introduce invocations of >>>> APIs [5], [6] and [7] in order to periodically poll and print >>>> statistics (may be with 1-second delay), which may, for example, >>>> shed light on mbuf allocation errors (extended stats). >>>> >>>> Do statistics display any interesting figures to be discussed? >>>> >>>> [3] >>>> https://doc/ >>>> .dpdk.org%2Fapi-25.03%2Frte__ethdev_8h.html%23a3e7d76a451b46348686ea >>>> 9 >>>> 7d6367f102&data=05%7C02%7CKR.Gokul%40in.bosch.com%7C53a20884cad14b94 >>>> 7 >>>> a0008ddc9aff5bf%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C6388884 >>>> 7 >>>> 9792853601%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL >>>> j >>>> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C >>>> % >>>> 7C&sdata=56BbJeMo6BtewrRGcnIIWBx4gxbvQKl7iATnoUpcTMc%3D&reserved=0 >>>> [4] >>>> https://doc/ >>>> .dpdk.org%2Fapi-25.03%2Frte__ethdev_8h.html%23a83e56cabbd31637efd648 >>>> e >>>> 3fc010392b&data=05%7C02%7CKR.Gokul%40in.bosch.com%7C53a20884cad14b94 >>>> 7 >>>> a0008ddc9aff5bf%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C6388884 >>>> 7 >>>> 9792862833%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL >>>> j >>>> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C >>>> % >>>> 7C&sdata=bDP8uNF03zuftWy%2BRbXKg1sYwv8DruMG53ntffCy%2BOk%3D&reserved >>>> = >>>> 0 >>>> >>>> [5] >>>> https://doc/ >>>> .dpdk.org%2Fapi-25.03%2Frte__ethdev_8h.html%23adec226574c53ae413252c >>>> 9 >>>> b15f6f4bab&data=05%7C02%7CKR.Gokul%40in.bosch.com%7C53a20884cad14b94 >>>> 7 >>>> a0008ddc9aff5bf%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C6388884 >>>> 7 >>>> 9792872496%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL >>>> j >>>> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C >>>> % >>>> 7C&sdata=dJ3yB2MTz28n2mQ5ogbYilcj4sr7K2JD723k5zWvlyU%3D&reserved=0 >>>> [6] >>>> https://doc/ >>>> .dpdk.org%2Fapi-25.03%2Frte__ethdev_8h.html%23a418ad970673eb17167318 >>>> 5 >>>> e36044fd79&data=05%7C02%7CKR.Gokul%40in.bosch.com%7C53a20884cad14b94 >>>> 7 >>>> a0008ddc9aff5bf%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C6388884 >>>> 7 >>>> 9792882662%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL >>>> j >>>> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C >>>> % >>>> 7C&sdata=aFt%2Fn%2B4FqX6cJDxWVRyWlZrAlVPXOqE6jV7Uymq7WQw%3D&reserved >>>> = >>>> 0 >>>> [7] >>>> https://doc/ >>>> .dpdk.org%2Fapi-25.03%2Frte__ethdev_8h.html%23a300d75b583c1f5acfe5b1 >>>> 6 >>>> 2a5d8c0ac1&data=05%7C02%7CKR.Gokul%40in.bosch.com%7C53a20884cad14b94 >>>> 7 >>>> a0008ddc9aff5bf%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C6388884 >>>> 7 >>>> 9792892124%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL >>>> j >>>> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C >>>> % >>>> 7C&sdata=TlmU3IaIKCzOEvsmFn8if%2BftgQq7ZJCuzcs6x%2B8jaAY%3D&reserved >>>> = >>>> 0 >>>> >>>>> >>>>> >>>>> ___________________________________________________________________ >>>>> _ >>>>> __ >>>>> ___________________________________________________________________ >>>>> _ __ ______________________________________________ >>>>> >>>>> >>>>> Environment Details: >>>>> >>>>> * NIC used: Intel I225/I210 >>>>> * Hugepages configured: 1 GB >>>>> * NUMA binding: --cpunodebind=0 --membind=0 >>>>> * OS: [Your Linux distribution, e.g., Ubuntu 20.04] >>>>> * DPDK version: [Mention if known] >>>>> >>>>> ___________________________________________________________________ >>>>> _ >>>>> __ >>>>> ___________________________________________________________________ >>>>> _ __ ______________________________________________ >>>>> >>>>> >>>>> Could you please advise if any additional setup, configuration, or >>>>> known limitations may be impacting the packet transmission? >>>> >>>> This may be a wild suggestion from my side, but it pays to check >>>> whether link status is "up" upon port start on both ends. One can >>>> use API [8] to do that. >>>> >>>> [8] >>>> https://doc/ >>>> .dpdk.org%2Fapi-25.03%2Frte__ethdev_8h.html%23ac05878578e4fd9ef3551d >>>> 2 >>>> c1c175ebe7&data=05%7C02%7CKR.Gokul%40in.bosch.com%7C53a20884cad14b94 >>>> 7 >>>> a0008ddc9aff5bf%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C6388884 >>>> 7 >>>> 9792901138%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL >>>> j >>>> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C >>>> % >>>> 7C&sdata=kLtuxeh0nYIV7UnU5WGLykXqngpIXzqHNsMlRG%2F89e0%3D&reserved=0 >>>> >>>> Thank you. >>>> >>>> >>>>> >>>>> Thank you in advance for your support! >>>>> >>>>> >>>>> Best regards, >>>>> Gokul K R >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> >