From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 8B4F44C8E for ; Sat, 3 Mar 2018 14:45:02 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2018 05:45:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,418,1515484800"; d="scan'208";a="179582290" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.21.107]) ([10.252.21.107]) by orsmga004.jf.intel.com with ESMTP; 03 Mar 2018 05:45:00 -0800 To: Stephen Hemminger Cc: dev@dpdk.org, jianfeng.tan@intel.com, konstantin.ananyev@intel.com References: <92186ea34a31743ed76dbd9267f0586da22575f3.1519742486.git.anatoly.burakov@intel.com> <20180302105127.3e6f274f@xeon-e3> From: "Burakov, Anatoly" Message-ID: <3688f7bf-cc1b-de00-8567-78e9a9ead335@intel.com> Date: Sat, 3 Mar 2018 13:44:59 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180302105127.3e6f274f@xeon-e3> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] eal: add asynchronous request API to DPDK IPC 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: Sat, 03 Mar 2018 13:45:02 -0000 On 02-Mar-18 6:51 PM, Stephen Hemminger wrote: > On Tue, 27 Feb 2018 14:59:29 +0000 > Anatoly Burakov wrote: > >> This API is similar to the blocking API that is already present, >> but reply will be received in a separate callback by the caller. >> >> Under the hood, we create a separate thread to deal with replies to >> asynchronous requests, that will just wait to be notified by the >> main thread, or woken up on a timer (it'll wake itself up every >> minute regardless of whether it was called, but if there are no >> requests in the queue, nothing will be done and it'll go to sleep >> for another minute). >> >> Signed-off-by: Anatoly Burakov > > The problem with this callback model is it makes it possible to > have a single wait for multiple events model (like epoll) which > is the most scaleable way to write applications. > > I assume there's a typo in there somewhere, because the way it's written makes it look like an advantage, not a problem :) Some more details on what exactly is the issue would be welcome though. -- Thanks, Anatoly