From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 47B8323C for ; Mon, 16 Jul 2018 17:01:54 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2018 08:01:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,361,1526367600"; d="scan'208,217";a="245657880" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga005.fm.intel.com with ESMTP; 16 Jul 2018 08:00:42 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 16 Jul 2018 08:00:41 -0700 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.10]) by FMSMSX102.amr.corp.intel.com ([169.254.10.201]) with mapi id 14.03.0319.002; Mon, 16 Jul 2018 08:00:41 -0700 From: "Eads, Gage" To: "dev@dpdk.org" CC: "Burakov, Anatoly" Thread-Topic: DPDK and forked processes Thread-Index: AdQdEjFibZn7P0/2SrWkZK8Y8z5Eyg== Date: Mon, 16 Jul 2018 15:00:41 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E446E9A79@FMSMSX108.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDcyZmEyMjEtNmQzOS00NWE3LTg5YzgtZDg3NzlhOTZmYzE0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiN1pRMnZ3TjZ2SGtMeDA0eUtpbTd1SDlcLytVSWQ3UFczc1FFMnhcL3FJSThYaWlKWWdSTjhNTUNcL2UyUWhnVDd5diJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.1.200.107] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [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: Mon, 16 Jul 2018 15:01:54 -0000 Hi all, Does DPDK support forking secondary processes after executing rte_eal_init(= )? The l2fwd_fork example and at least one application (OpenEM: https://sou= rceforge.net/projects/eventmachine/) use this model, and they do so by fixi= ng up the EAL internals (e.g. manually changing process_type from primary t= o 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 cha= nges. For instance, the multi-process communication creates a couple handle= r threads ("rte_mp_handle" and "rte_mp_async") during EAL initialization. T= he child processes won't inherit these threads, and so won't be able to par= ticipate in multi-process comms. This means the reworked memory subsystem a= nd 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 eithe= r drop the example and not support this model, or support it and either doc= ument its limitations or resolve them. This model could be an interesting w= ay to run multi-process DPDK on an ASLR-enabled system, but supporting this= wouldn't be trivial. Thanks, Gage