27/07/2018 15:46, Eads, Gage: > As this discussion has broad implications for DPDK, is it a good candidate > for a techboard meeting topic?
We can discuss it in techboard, but usually we prefer discussing topics whose resolution is not clear. In this case, I think everybody agree with Anatoly, isn't it? > > -----Original Message----- > > From: Burakov, Anatoly > > Sent: Monday, July 16, 2018 10:09 AM > > To: Eads, Gage <gage.e...@intel.com>; dev@dpdk.org > > Subject: Re: DPDK and forked processes > > > > On 16-Jul-18 4:00 PM, Eads, Gage wrote: > > > 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 > > > > > > > I think it's a very bad idea to use such a model in recent versions of > > DPDK. As you > > have correctly pointed out, IPC will not work in such a scenario, and given > > how > > our memory subsystem relies on IPC, this is a recipe for memory corruption > > and > > divergent memory maps (since technically both initial and forked processes > > believe they are primary). > > > > Even hacking rte_config to make DPDK think it's a secondary process will not > > work, because the initialization has already completed, but all of the > > threads > > (IPC, interrupt, etc.) are gone and correct IPC socket was not created, > > which > > means the process becomes invisible to the primary for all intents and > > purposes. > > > > We _could_ introduce some kind of "official DPDK fork" function that would > > fork > > the process and then restart interrupt, IPC etc. stuff on an already running > > instance of DPDK, but that seems like a workaround for a problem that > > shouldn't > > exist in the first place, because such usage is fundamentally incompatible > > with > > DPDK as it stands now. > > > > -- > > Thanks, > > Anatoly >
