Hi all,

Does DPDK support forking secondary processes after executing rte_eal_init()? 
The l2fwd_fork example and at least one application (OpenEM: 
https://sourceforge.net/projects/eventmachine/) use this model, and they do so 
by fixing up the EAL internals (e.g. manually changing process_type from 
primary to secondary) at the start of the child process. This feels like a 
hack, and I can't find any documentation describing this model.

Moreover, this approach doesn't appear to be compatible with recent EAL 
changes. For instance, the multi-process communication creates a couple handler 
threads ("rte_mp_handle" and "rte_mp_async") during EAL initialization. The 
child processes won't inherit these threads, and so won't be able to 
participate in multi-process comms. This means the reworked memory subsystem 
and upcoming device hotplug support 
(http://mails.dpdk.org/archives/dev/2018-July/107704.html) won't work with this 
fork-after-init model.

This is just one example - there may be other features/subsystems that won't 
work. As far as I can tell there is no official stance (though the l2fwd_fork 
example implies it's supported, IMO); I think either DPDK should either drop 
the example and not support this model, or support it and either document its 
limitations or resolve them. This model could be an interesting way to run 
multi-process DPDK on an ASLR-enabled system, but supporting this wouldn't be 
trivial.

Thanks,
Gage

Reply via email to