From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id E260C1B48B for ; Tue, 26 Jun 2018 11:24:20 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 70ACD21F8A; Tue, 26 Jun 2018 05:24:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 26 Jun 2018 05:24:20 -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=EUJtNffnPsXCzptofQ2g8x93lY WnT2SXckQ1QAIQPB4=; b=FaISI/Otl4WcLbFQwyVOWRqb4MwAwevUvp07Nj1Yvq 3ESkqb3bAYHOBfkMh7UQhdftiIIcvbGNS9mdAdqDKAadmSugt4sjGVN0Aowrmmnt eK53R/5jBqAt0FVhNQ35qc9Qoj/IX7u22MofHlH4SrvAQzMSBFGt0ehc21ibXiSP 4= 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=EUJtNf fnPsXCzptofQ2g8x93lYWnT2SXckQ1QAIQPB4=; b=tvLHer/Ar43H0eeDaqPmxU +hY2oI/ND91gW0C2z/MKNdLYTrNygCI173nIsys4rEpucfQtkuHb4hEtjcnfKbym FjCaSJW5VMQn9BM3/uASyyCs7k4fv0Zjmx17KrG6XIy+aDmOb+jN8Ll+ZztJPbtH ZDjJPGo0UHlIR+CxmSL8+YmhFqf5vLa+6OzzmOBUOVTJKNlCWPJvGZWlIuOH4Pch IT87BtC83SaxMzdi/KAvltK5qLUbAYlXdQu0fTf6VuxtloywLMRPSMPqkt8FwuOD 41y0m2+tIWoacQrlNygMZDvGHsSKl73Ce3gEdfQoMqbIM7OeGKpb7luq5tRUySnQ == 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 650AE10292; Tue, 26 Jun 2018 05:24:19 -0400 (EDT) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: Qi Zhang , konstantin.ananyev@intel.com, dev@dpdk.org, bruce.richardson@intel.com, ferruh.yigit@intel.com, benjamin.h.shelton@intel.com, narender.vangati@intel.com Date: Tue, 26 Jun 2018 11:24:18 +0200 Message-ID: <3228714.zAXYVjxDgJ@xps> In-Reply-To: <167506ed-380a-898e-2f52-20be0178a49b@intel.com> References: <20180607123849.14439-1-qi.z.zhang@intel.com> <20180626070832.3055-6-qi.z.zhang@intel.com> <167506ed-380a-898e-2f52-20be0178a49b@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:24:21 -0000 26/06/2018 11:02, Burakov, Anatoly: > 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) We can keep one IPC thread until we find a better solution.