From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tan, Jianfeng" Subject: Re: [PATCH v2 07/12] eal: add channel for primary/secondary communication Date: Sat, 30 Sep 2017 12:07:50 +0800 Message-ID: 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: 7bit Cc: "Ananyev, Konstantin" , "Richardson, Bruce" , "Pattan, Reshma" , "viktorin@rehivetech.com" To: "Burakov, Anatoly" , "dev@dpdk.org" Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 2FB302BAA for ; Sat, 30 Sep 2017 06:07:53 +0200 (CEST) In-Reply-To: <992217df-6bfb-063c-e3e6-11930c5108da@intel.com> 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 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