From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id A02BF1B017 for ; Tue, 16 Jan 2018 12:12:53 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 03:12:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,368,1511856000"; d="scan'208";a="10103180" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga007.jf.intel.com with ESMTP; 16 Jan 2018 03:12:48 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.236]) by IRSMSX102.ger.corp.intel.com ([169.254.2.180]) with mapi id 14.03.0319.002; Tue, 16 Jan 2018 11:12:48 +0000 From: "Ananyev, Konstantin" To: "Tan, Jianfeng" , "dev@dpdk.org" , "Burakov, Anatoly" CC: "Richardson, Bruce" , "thomas@monjalon.net" Thread-Topic: [PATCH v2 3/4] eal: add synchronous multi-process communication Thread-Index: AQHTipGGLptO92489k+SILW6rHFPTqN1nPiQgACQ2ICAADIq4A== Date: Tue, 16 Jan 2018 11:12:47 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772588627E2D8@irsmsx105.ger.corp.intel.com> References: <1512067450-59203-1-git-send-email-jianfeng.tan@intel.com> <1515643654-129489-1-git-send-email-jianfeng.tan@intel.com> <1515643654-129489-4-git-send-email-jianfeng.tan@intel.com> <2601191342CEEE43887BDE71AB9772588627E0E5@irsmsx105.ger.corp.intel.com> <5733adcf-ef47-2c07-a39c-7eda01add6e0@intel.com> In-Reply-To: <5733adcf-ef47-2c07-a39c-7eda01add6e0@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGIwZmE2MmUtMmE1OS00YTE4LWJiODUtMjkyMjA3OGMyZGQ4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlZzampuOEVQWVZGcmFxNGdaXC9zVmxjQ1dcL3lyKzRhZnEwK2ZORTJIdEhHWT0ifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 3/4] eal: add synchronous multi-process communication 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, 16 Jan 2018 11:12:54 -0000 Hi Jianfeng, > -----Original Message----- > From: Tan, Jianfeng > Sent: Tuesday, January 16, 2018 8:11 AM > To: Ananyev, Konstantin ; dev@dpdk.org; Bur= akov, Anatoly > Cc: Richardson, Bruce ; thomas@monjalon.net > Subject: Re: [PATCH v2 3/4] eal: add synchronous multi-process communicat= ion >=20 > Thank you, Konstantin and Anatoly firstly. Other comments are well > received and I'll send out a new version. >=20 >=20 > On 1/16/2018 8:00 AM, Ananyev, Konstantin wrote: > > > >> We need the synchronous way for multi-process communication, > >> i.e., blockingly waiting for reply message when we send a request > >> to the peer process. > >> > >> We add two APIs rte_eal_mp_request() and rte_eal_mp_reply() for > >> such use case. By invoking rte_eal_mp_request(), a request message > >> is sent out, and then it waits there for a reply message. The > >> timeout is hard-coded 5 Sec. And the replied message will be copied > >> in the parameters of this API so that the caller can decide how > >> to translate those information (including params and fds). Note > >> if a primary process owns multiple secondary processes, this API > >> will fail. > >> > >> The API rte_eal_mp_reply() is always called by an mp action handler. > >> Here we add another parameter for rte_eal_mp_t so that the action > >> handler knows which peer address to reply. > >> > >> We use mutex in rte_eal_mp_request() to guarantee that only one > >> request is on the fly for one pair of processes. > > You don't need to do things in such strange and restrictive way. > > Instead you can do something like that: > > 1) Introduce new struct, list for it and mutex > > struct sync_request { > > int reply_received; > > char dst[PATH_MAX]; > > char reply[...]; > > LIST_ENTRY(sync_request) next; > > }; > > > > static struct > > LIST_HEAD(list, sync_request); > > pthread_mutex_t lock; > > pthead_cond_t cond; > > } sync_requests; > > > > 2) then at request() call: > > Grab sync_requests.lock > > Check do we already have a pending request for that destination, > > If yes - the release the lock and returns with error. > > - allocate and init new sync_request struct, set reply_received=3D0 > > - do send_msg() > > -then in a cycle: > > pthread_cond_timed_wait(&sync_requests.cond, &sync_request.lock, &ti= mespec); > > - at return from it check if sync_request.reply_received =3D=3D 1, i= f not > > check if timeout expired and either return a failure or go to the start= of the cycle. > > > > 3) at mp_handler() if REPLY received - grab sync_request.lock, > > search through sync_requests.list for dst[] , > > if found, then set it's reply_received=3D1, copy the received messa= ge into reply > > and call pthread_cond_braodcast((&sync_requests.cond); >=20 > The only benefit I can see is that now the sender can request to > multiple receivers at the same time. And it makes things more > complicated. Do we really need this? The benefit is that one thread is blocked waiting for response, your mp_handler can still receive and handle other messages. Plus as you said - other threads can keep sending messages. Konstantin=20 >=20 > Thanks, > Jianfeng