From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: [PATCH v2 07/12] eal: add channel for primary/secondary communication Date: Mon, 2 Oct 2017 11:08:58 +0100 Message-ID: <9ebf5003-ee17-df40-2344-fb6366a94b9a@intel.com> References: <1503654052-84730-1-git-send-email-jianfeng.tan@intel.com> <1506606959-76230-1-git-send-email-jianfeng.tan@intel.com> <1506606959-76230-8-git-send-email-jianfeng.tan@intel.com> <2601191342CEEE43887BDE71AB9772584F24FF69@irsmsx105.ger.corp.intel.com> <992217df-6bfb-063c-e3e6-11930c5108da@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Ananyev, Konstantin" , "Richardson, Bruce" , "Pattan, Reshma" , "viktorin@rehivetech.com" To: "Tan, Jianfeng" , "dev@dpdk.org" Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 0349A1B1ED for ; Mon, 2 Oct 2017 12:09:02 +0200 (CEST) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 30-Sep-17 5:07 AM, Tan, Jianfeng wrote: > > > On 9/29/2017 6:00 PM, Burakov, Anatoly wrote: >> On 29-Sep-17 2:03 AM, Tan, Jianfeng wrote: >>> + Reshma and Jan. >>> >>>> -----Original Message----- >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Burakov, Anatoly >>>> Sent: Thursday, September 28, 2017 11:30 PM >>>> To: dev@dpdk.org >>>> Subject: Re: [dpdk-dev] [PATCH v2 07/12] eal: add channel for >>>> primary/secondary communication >>>> >>>> On 28-Sep-17 4:01 PM, Ananyev, Konstantin wrote: >>>>> Hi Jianfeng, >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Tan, Jianfeng >>>>>> Sent: Thursday, September 28, 2017 2:56 PM >>>>>> To: dev@dpdk.org >>>>>> Cc: Richardson, Bruce ; Ananyev, >>>> Konstantin ; De Lara Guarch, Pablo >>>>>> ; thomas@monjalon.net; >>>> yliu@fridaylinux.org; maxime.coquelin@redhat.com; mtetsuyah@gmail.com; >>>>>> Yigit, Ferruh ; Tan, Jianfeng >>>> >>>>>> Subject: [PATCH v2 07/12] eal: add channel for primary/secondary >>>> communication >>>>>> >>>>>> Previouly, there is only one way for primary/secondary to exchange >>>>>> messages, that is, primary process writes info into some predefind >>>>>> file, and secondary process reads info out. That cannot address >>>>>> the requirements: >>>>>>     a. Secondary wants to send info to primary, for example, >>>>>> secondary >>>>>>        would like to send request (about some specific vdev to >>>>>> primary). >>>>>>     b. Sending info at any time, instead of just initialization time. >>>>>>     c. Share FDs with the other side, for vdev like vhost, related >>>>>> FDs >>>>>>        (memory region, kick) should be shared. >>>>>> >>>>>> This patch proposes to create a communication channel, as an unix >>>>>> socket connection, for above requirements. Primary will listen on >>>>>> the unix socket; secondary will connect this socket to talk. >>>>>> >>>>>> Three new APIs are added: >>>>>> >>>>>>     1. rte_eal_mp_action_register is used to register an action, >>>>>>        indexed by a string; if the calling component wants to >>>>>>        response the messages from the corresponding component in >>>>>>        its primary process or secondary processes. >>>>>>     2. rte_eal_mp_action_unregister is used to unregister the action >>>>>>        if the calling component does not want to response the >>>>>> messages. >>>>>>     3. rte_eal_mp_sendmsg is used to send a message. >>>>> >>>>> I think we already have similar channel in librte_pdump(). >>>>> Also it seems like eal_vfio also has it's own socket to communicate >>>> between mp/sp. >>>>> Could we probably make it generic - so same code (and socket) be >>>>> used by >>>> all such  places. >>>>> Konstantin >>>>> >>>> >>>> Agreed, however looking at this, it's already a generic-enough >>>> solution, >>>> and other places could be fixed to use this in later releases. >>> >>> Yes, to provide a generic communication way, instead of one channel >>> for each subsystem, is the goal of this patch. >>> >>> Reshma and Jan, can I ask comment from you to have a look if the way >>> of this patch is generic enough to cover pdump and vfio-sync's >>> requirement? >>> >>> Possible limitation of this patch (so far) is that it only provides >>> an async way for request/response, do we need synchronous way? >>> >>>> That said, i believe this particular part of the patchset should go >>>> in as a >>>> separate patchset and more design consideration and input from others. >>> >>> OK, let's collect more info here, and then take out this patch out as >>> a separate patch. >>> >>> Thanks, >>> Jianfeng >>> >> Hi Jianfeng, >> >> Yes, i believe VFIO does need synchronous communcation, because it >> relies on passing fd's from primary to secondary, on request. It could >> be rewritten to be asynchronous, similarly to how you handle vdevs >> here, but as it stands, it assumes synchronous communication. >> > > Good to know, thanks Anatoly. Even it can be rewritten to do in asyn > way, do we need to propose sync way now? > > Thanks, > Jianfeng > I believe that we do, because we can't assume that everything can be rewritten to be asynchronous. I'm open to other opinions though :) -- Thanks, Anatoly