From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 6B1451B60A for ; Tue, 26 Jun 2018 15:46:14 +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 orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 06:46:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,274,1526367600"; d="scan'208";a="67395755" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.28]) ([10.237.220.28]) by fmsmga001.fm.intel.com with ESMTP; 26 Jun 2018 06:45:59 -0700 To: "Zhang, Qi Z" , "thomas@monjalon.net" Cc: "Ananyev, Konstantin" , "dev@dpdk.org" , "Richardson, Bruce" , "Yigit, Ferruh" , "Shelton, Benjamin H" , "Vangati, Narender" References: <20180607123849.14439-1-qi.z.zhang@intel.com> <20180626070832.3055-1-qi.z.zhang@intel.com> <20180626070832.3055-7-qi.z.zhang@intel.com> <969f0cb7-4186-d05c-442f-6341f1c44e93@intel.com> <039ED4275CED7440929022BC67E706115323E71A@SHSMSX103.ccr.corp.intel.com> <30b1c93c-1d7c-07d9-d41a-76e84f63d6a1@intel.com> <039ED4275CED7440929022BC67E706115323E7A5@SHSMSX103.ccr.corp.intel.com> <365fd549-14c6-ae72-84be-3ec7389eaa84@intel.com> <039ED4275CED7440929022BC67E706115323E7E2@SHSMSX103.ccr.corp.intel.com> From: "Burakov, Anatoly" Message-ID: <53fe3a3e-ae37-0765-f83d-c88a279028a1@intel.com> Date: Tue, 26 Jun 2018 14:45:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <039ED4275CED7440929022BC67E706115323E7E2@SHSMSX103.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 06/24] ethdev: enable hotplug on multi-process 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 13:46:15 -0000 On 26-Jun-18 2:25 PM, Zhang, Qi Z wrote: > > >> -----Original Message----- >> From: Burakov, Anatoly >> Sent: Tuesday, June 26, 2018 9:21 PM >> To: Zhang, Qi Z ; thomas@monjalon.net >> Cc: Ananyev, Konstantin ; dev@dpdk.org; >> Richardson, Bruce ; Yigit, Ferruh >> ; Shelton, Benjamin H >> ; Vangati, Narender >> >> Subject: Re: [PATCH v4 06/24] ethdev: enable hotplug on multi-process >> >> On 26-Jun-18 1:58 PM, Zhang, Qi Z wrote: >>> >>> my understand is peer is identified by a string (or filename) what I >>> mean is clone the content of the buffer that peer point to , So I >>> don't need to worry if the original peer be used to point to some >>> other data >>> >> >> As far as the application is concerned, peer is an opaque pointer, and should >> be treated as such. Peeking behind a void pointer that is not designed for this >> purpose is not a good idea, even if technically you know what's in there. > > We can expose a clone interface, like MP_PEER_CLONE, so we don't need to know what's inside, just need to know that it can be used on another thread? > Well, that can probably work. Feels like a hacky workaround though. Another way to do the same thing would be to store peer information right in the message, as opposed to providing it separately. Still a hack though, and will require far more changes, but it could be a better solution as (if done right) it would allow identifying which reply came from which peer. Of course, an even better approach would be to devise some kind of addressing scheme (uuid?), so that peer addresses are no longer opaque pointers but rather are valid data types. Thoughts? -- Thanks, Anatoly