From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 276EF1B4B5 for ; Tue, 26 Jun 2018 12:53:25 +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 fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 03:53:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,274,1526367600"; d="scan'208";a="67358863" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by fmsmga001.fm.intel.com with ESMTP; 26 Jun 2018 03:53:21 -0700 Received: from sivswdev01.ir.intel.com (sivswdev01.ir.intel.com [10.237.217.45]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id w5QArKKY026454; Tue, 26 Jun 2018 11:53:20 +0100 Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1]) by sivswdev01.ir.intel.com with ESMTP id w5QArKm1021231; Tue, 26 Jun 2018 11:53:20 +0100 Received: (from aburakov@localhost) by sivswdev01.ir.intel.com with LOCAL id w5QArKfo021227; Tue, 26 Jun 2018 11:53:20 +0100 From: Anatoly Burakov To: dev@dpdk.org Cc: John McNamara , Marko Kovacevic , konstantin.ananyev@intel.com, thomas@monjalon.net, bruce.richardson@intel.com, qi.z.zhang@intel.com Date: Tue, 26 Jun 2018 11:53:18 +0100 Message-Id: X-Mailer: git-send-email 1.7.0.7 In-Reply-To: References: In-Reply-To: References: Subject: [dpdk-dev] [PATCH v2 7/7] doc: document IPC callback limitations 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 10:53:26 -0000 For asynchronous requests, user callback may be triggered either from IPC thread or from interrupt thread. Because of this, delivery of other interrupt-based events such as alarms may not be possible inside the asynchronous IPC request callback handler. Document this limitation. Signed-off-by: Anatoly Burakov --- doc/guides/prog_guide/multi_proc_support.rst | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst index 46a00ec11..1384fe335 100644 --- a/doc/guides/prog_guide/multi_proc_support.rst +++ b/doc/guides/prog_guide/multi_proc_support.rst @@ -220,8 +220,8 @@ way communication mechanism, with the requester expecting a response from the other side. Both messages and requests will trigger a named callback on the receiver side. -These callbacks will be called from within a dedicated IPC thread that is not -part of EAL lcore threads. +These callbacks will be called from within a dedicated IPC or interrupt thread +that are not part of EAL lcore threads. Registering for incoming messages ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -280,6 +280,13 @@ For asynchronous requests, a function pointer to the callback function must be provided instead. This callback will be called when the request either has timed out, or will have received a response to all the messages that were sent. +.. warning:: + + When an asynchronous request times out, the callback will be called not by + a dedicated IPC thread, but rather from EAL interrupt thread. Because of + this, it may not be possible for DPDK to trigger another interrupt-based + event (such as an alarm) while handling asynchronous IPC callback. + When the callback is called, the original request descriptor will be provided (so that it would be possible to determine for which sent message this is a callback to), along with a response descriptor like the one described above. @@ -311,6 +318,12 @@ supported. However, since sending messages (not requests) does not involve an IPC thread, sending messages while processing another message or request is supported. +Asynchronous request callbacks may be triggered either from IPC thread or from +interrupt thread, depending on whether the request has timed out. It is +therefore suggested to avoid waiting for interrupt-based events (such as alarms) +inside asynchronous IPC request callbacks. This limitation does not apply to +messages or synchronous requests. + If callbacks spend a long time processing the incoming requests, the requestor might time out, so setting the right timeout value on the requestor side is imperative. -- 2.17.1