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 3ACEB237 for ; Mon, 11 Dec 2017 10:59:48 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2017 01:59:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,391,1508828400"; d="scan'208";a="185904972" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.117]) ([10.237.220.117]) by fmsmga006.fm.intel.com with ESMTP; 11 Dec 2017 01:59:46 -0800 To: Jianfeng Tan , dev@dpdk.org Cc: bruce.richardson@intel.com, konstantin.ananyev@intel.com, thomas@monjalon.net References: <1512067450-59203-1-git-send-email-jianfeng.tan@intel.com> From: "Burakov, Anatoly" Message-ID: <3b6c4096-b68b-d5e3-9dc3-f48fa99dba8e@intel.com> Date: Mon, 11 Dec 2017 09:59:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1512067450-59203-1-git-send-email-jianfeng.tan@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 0/3] generic channel for 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: Mon, 11 Dec 2017 09:59:49 -0000 On 30-Nov-17 6:44 PM, Jianfeng Tan wrote: > This patchset adds a generic channel for multi-process (primary/secondary) > communication. > > Patch 1: addess the purpose and howto; > Patch 2: add a syncrhonous way for those messages which need a response immediately. > Patch 3: Rework vfio to use this generic communication channel. > Hi Jianfeng, Just a general comment: I am assuming this has the limitation of "everything happens through primary process's involvement". This will work for VFIO, as secondary always needs to ask the primary before doing anything, but it doesn't address other issues that could have been addressed with IPC. For example, if a primary process would've hotplugged a device, it can't notify all secondary processes about this; rather, it has to wait until secondary processes ask for this info. Neither can it do anything if secondary requests a primary to do something, and notify other secondary processes about it (i.e. if secondary wants to hotplug a device, but there are other secondaries also running). It would be great to have a standard way of doing things like this in future revisions of our IPC. -- Thanks, Anatoly