[Public] HI,
Snipped Hi, You can create a simple setup with only running testpmd with primary and another testpmd with secondary and then see the results. No, the reason for the primary process termination could be close or shutdown (ctrl + c or ctrl + q) or any other. The reason is clear: "In secondary processes, accessing 'dev->data->dev_private' or &dev->data->mac_addrs directly can cause a segmentation fault if the primary process has exited or the shared memory is unavailable." The effect is throughput the life-cycle of secondary process existence in dpdk after primary, You can check https://patches.dpdk.org/project/dpdk/patch/20250721073851.963141-1-14pwcse1...@uetpeshawar.edu.pk/ https://patches.dpdk.org/project/dpdk/patch/20250721105522.1019515-1-14pwcse1...@uetpeshawar.edu.pk/ I think most of the details have already been provided. The community agrees with the current solution. Thanks. There are couple of corrections that needs to shared to the current understanding you are sharing 1. Please find DPDK Documentation on mutli process as 4. Multi-process Support — Data Plane Development Kit 25.07.0 documentation<https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html> 2. From your ` This patch only adds stability and robustness to primary-secondary applications.` this is not true 3. ` any other application which provides primary-secondary support could also follow the same model` - actually by default the eal args supports mutli process. Only by specifying `--single-process` this is disabled 4. ` the reason for the primary process termination could be close or shutdown (ctrl + c or ctrl + q)` DPDK testpmd and a few examples like L2fwd, eventdev, l3fwd and other uses SIGACTION to check gracefully exit 1. In all graceful exit `rte_eal_cleanup is invoked`. Hence any secondary (as shared in my previous emails) will have dangling pointers. 2. For customer till 2023 and internal testing (as mentioned in my email) any abrupt kill of primary does not corrupt the secondary rte_eth_dev_list. From patch perspective https://patches.dpdk.org/project/dpdk/patch/20250721073851.963141-1-14pwcse1...@uetpeshawar.edu.pk/ what Stephen shared is correct, PMD are not incharge of process aliveness. It is correct hence NAK net/ice: fix segfault in secondary process by validating dev_private pointer - Patchwork<https://patches.dpdk.org/project/dpdk/patch/20250721105522.1019515-1-14pwcse1...@uetpeshawar.edu.pk/> trying to do in ICE driver should be NAK From solution perspective, in my earlier email I clearly asked why have not explored multi-process communication thread. Link to it is same as above under section ` 4.4. Communication between multiple processes` You could always design when ` (ctrl + c or ctrl + q)` primary can send a broadcast to all secondaries to stop eth, event, bbdev or any such execution or simply exit. This is what we designed and shared as working logic. Note: You have also mentioned ` The community agrees with the current solution. ` which paints a picture of 1. Only there is one way to solve this problem. 2. Since I did not agree to your thought process I am not community. Personally, I am not happy with such biases, DPDK had been supporting and nurturing open healthy conversation and platform. I am not aware this was changed.
