From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 4CBF71B426 for ; Tue, 26 Jun 2018 11:02:55 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 02:02:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,274,1526367600"; d="scan'208";a="67333046" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.28]) ([10.237.220.28]) by fmsmga001.fm.intel.com with ESMTP; 26 Jun 2018 02:02:51 -0700 To: Qi Zhang , thomas@monjalon.net Cc: konstantin.ananyev@intel.com, dev@dpdk.org, bruce.richardson@intel.com, ferruh.yigit@intel.com, benjamin.h.shelton@intel.com, narender.vangati@intel.com References: <20180607123849.14439-1-qi.z.zhang@intel.com> <20180626070832.3055-1-qi.z.zhang@intel.com> <20180626070832.3055-6-qi.z.zhang@intel.com> From: "Burakov, Anatoly" Message-ID: <167506ed-380a-898e-2f52-20be0178a49b@intel.com> Date: Tue, 26 Jun 2018 10:02:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180626070832.3055-6-qi.z.zhang@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 05/24] eal: support mp task be invoked in a separate task 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: Tue, 26 Jun 2018 09:02:55 -0000 On 26-Jun-18 8:08 AM, Qi Zhang wrote: > We know the limitation that sync IPC can't be invoked in mp handler > itself which will cause deadlock, the patch introduce new API > rte_eal_mp_task_add to support mp handler be delegated in a separate > task. > > Signed-off-by: Qi Zhang > --- I would really like to find another solution to this problem. Creating a new thread per hotplug request seems like an overkill - even more so than having two threads. Creating a new thread potentially while the application is working may have other implications (e.g. there's a non-zero amount of time between thread created and thread affinitized, which may disrupt hotpaths). It seems to me that the better solution would've been to leave the IPC thread in place. There are two IPC threads in the first place because there was a circular dependency between rte_malloc and alarm API. My patch fixes that - so how about we remove *one* IPC thread, but leave the other one in place? Thomas, any thoughts? (quick description - hotplug needs IPC, and hotplug may need to allocate memory, which also needs IPC, which will cause a deadlock if IPC is one thread) -- Thanks, Anatoly