From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id D9DC325D9 for ; Fri, 27 Jul 2018 17:03:55 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6736421193; Fri, 27 Jul 2018 11:03:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 27 Jul 2018 11:03:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=Fqe9oTkOYroxr+WiErnYCi6Sn5 ZyWFF08mxJ11VC6/g=; b=cPmBHYfXSGezLc85sqEei14EQQUN1FHU1V2kAaaM2u rz9cRLF/SFGk51kSRsEw1tL2/Zm67gKjKTvvF1rNwIosKa+DhcStXfP1tPOd9jYX or9DLFXORiLwa3vEZC68pB5lE7E3qEi+Ai3H1o1yiqo2OUnsrxFpvCjHJ8/pVzaz k= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Fqe9oT kOYroxr+WiErnYCi6Sn5ZyWFF08mxJ11VC6/g=; b=qqNRxdBMF6nTDLKBStM7az pXDYOX4N5b2NJM0jhCwJT5yGysvP+F9y83IVDmtg5qUt6G/rhGg/x8Cke/qpD0hP sYmyEY89s6+UJYL737THSFagf4L0ky4Y7bbLwYMHE4tJwNJImfcRhiBduwJlDILK 6/it1ouM4f9jRgvA2LRoJhMLSVKw7x5cDxpvdIO8BUAJnwo88LZnHJ4WUbeHmaPd CjHquUlYeUKZnexHhbH1o8t+HoHNjsn/987A2vXa5hX0nBNvjQKIeV2K6zNmUL+s i2oT3zD3I+SlCCSdC1JcQKDMOr9dLwbyy2u61+tDfNC0H86jRLM2A+DoUD05DVPQ == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4982FE49AD; Fri, 27 Jul 2018 11:03:53 -0400 (EDT) From: Thomas Monjalon To: "Eads, Gage" Cc: "Burakov, Anatoly" , "dev@dpdk.org" , "Richardson, Bruce" , "jerin.jacob@caviumnetworks.com" , "Yigit, Ferruh" , "hemant.agrawal@nxp.com" , "Ananyev, Konstantin" , Olivier Matz , "stephen@networkplumber.org" Date: Fri, 27 Jul 2018 17:03:48 +0200 Message-ID: <7441138.EijKcuSYIv@xps> In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E446F214F@FMSMSX108.amr.corp.intel.com> References: <9184057F7FC11744A2107296B6B8EB1E446E9A79@FMSMSX108.amr.corp.intel.com> <9184057F7FC11744A2107296B6B8EB1E446F214F@FMSMSX108.amr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] DPDK and forked processes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:03:56 -0000 27/07/2018 15:46, Eads, Gage: > As this discussion has broad implications for DPDK, is it a good candidat= e for a techboard meeting topic?=20 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 ; dev@dpdk.org > > Subject: Re: DPDK and forked processes > >=20 > > 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=E2=80=99t find any > > > documentation describing this model. > > > > > > Moreover, this approach doesn=E2=80=99t appear to be compatible with = recent > > > EAL changes. For instance, the multi-process communication creates a > > > couple handler threads (=E2=80=9Crte_mp_handle=E2=80=9D and =E2=80=9C= rte_mp_async=E2=80=9D) during EAL > > > initialization. The child processes won=E2=80=99t inherit these threa= ds, and > > > so won=E2=80=99t 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=E2=80= =99t work > > > with this fork-after-init model. > > > > > > This is just one example =E2=80=93 there may be other features/subsys= tems that > > > won=E2=80=99t work. As far as I can tell there is no official stance = (though > > > the l2fwd_fork example implies it=E2=80=99s 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=E2=80=99t be trivial. > > > > > > Thanks, > > > > > > Gage > > > > >=20 > > 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 g= iven how > > our memory subsystem relies on IPC, this is a recipe for memory corrupt= ion and > > divergent memory maps (since technically both initial and forked proces= ses > > believe they are primary). > >=20 > > Even hacking rte_config to make DPDK think it's a secondary process wil= l 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. > >=20 > > We _could_ introduce some kind of "official DPDK fork" function that wo= uld fork > > the process and then restart interrupt, IPC etc. stuff on an already ru= nning > > instance of DPDK, but that seems like a workaround for a problem that s= houldn't > > exist in the first place, because such usage is fundamentally incompati= ble with > > DPDK as it stands now. > >=20 > > -- > > Thanks, > > Anatoly >=20