From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 146DD1B8D4 for ; Tue, 10 Apr 2018 16:17:27 +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 orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2018 07:17:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,432,1517904000"; d="scan'208";a="219265325" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.128]) ([10.237.220.128]) by fmsmga005.fm.intel.com with ESMTP; 10 Apr 2018 07:17:15 -0700 To: "Tan, Jianfeng" , dev@dpdk.org References: From: "Burakov, Anatoly" Message-ID: <80b09df6-9c31-dc91-e26b-8dfde14a2fb0@intel.com> Date: Tue, 10 Apr 2018 15:17:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] eal/ipc: stop async IPC loop on callback request 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, 10 Apr 2018 14:17:28 -0000 On 10-Apr-18 2:53 PM, Tan, Jianfeng wrote: > > > On 4/10/2018 6:03 PM, Anatoly Burakov wrote: >> EAL did not stop processing further asynchronous requests on >> encountering a request that should trigger the callback. This >> resulted in erasing valid requests but not triggering them. > > That means one wakeup could process multiple replies, and following > process_async_request() will erase some valid requests? Yes. > >> >> Fix this by stopping the loop once we have a request that we >> can trigger. Also, remove unnecessary check for trigger >> request being NULL. >> >> Fixes: f05e26051c15 ("eal: add IPC asynchronous request") >> Cc: anatoly.burakov@intel.com >> >> Signed-off-by: Anatoly Burakov > > >> --- >>   lib/librte_eal/common/eal_common_proc.c | 4 ++-- >>   1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/lib/librte_eal/common/eal_common_proc.c >> b/lib/librte_eal/common/eal_common_proc.c >> index f98622f..1ea3b58 100644 >> --- a/lib/librte_eal/common/eal_common_proc.c >> +++ b/lib/librte_eal/common/eal_common_proc.c >> @@ -510,11 +510,11 @@ async_reply_handle(void *arg __rte_unused) >>                       TAILQ_REMOVE(&pending_requests.requests, >>                               sr, next); >>                       free(sr); >> -                } else if (action == ACTION_TRIGGER && >> -                        trigger == NULL) { >> +                } else if (action == ACTION_TRIGGER) { >>                       TAILQ_REMOVE(&pending_requests.requests, >>                               sr, next); >>                       trigger = sr; >> +                    break; > > If I understand it correctly above, break here, we will trigger an async > action, and then go back to sleep with some ready requests not handled? > Seems that we shall unlock, process, and lock here. Right? Well, we won't go back to sleep - we'll just loop around and come back. See eal_common_proc.c:472: /* sometimes, we don't even wait */ if (sr->reply_received) { nowait = true; break; } Followed by line 478: if (nowait) ret = 0; Followed by line 495: if (ret == 0 || ret == ETIMEDOUT) { So, having messages with replies already in the queue will cause wait to be cancelled. It's not much slower than unlocking, triggering, and locking again. However, if you're OK with lock-loop-unlock-trigger-lock-loop-unlock-... sequence until we run out of triggers, then sure, i can add that. > > Thanks, > Jianfeng > >>                   } >>               } >>           } > > -- Thanks, Anatoly