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 9E37F1B21E for ; Fri, 29 Sep 2017 12:00:26 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2017 03:00:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,452,1500966000"; d="scan'208";a="156930413" Received: from aburakov-mobl2.ger.corp.intel.com (HELO [10.252.17.97]) ([10.252.17.97]) by fmsmga005.fm.intel.com with ESMTP; 29 Sep 2017 03:00:23 -0700 To: "Tan, Jianfeng" , "dev@dpdk.org" Cc: "Ananyev, Konstantin" , "Richardson, Bruce" , "Pattan, Reshma" , "viktorin@rehivetech.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> From: "Burakov, Anatoly" Message-ID: <992217df-6bfb-063c-e3e6-11930c5108da@intel.com> Date: Fri, 29 Sep 2017 11:00:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 07/12] eal: add channel for primary/secondary 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: Fri, 29 Sep 2017 10:00:27 -0000 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. -- Thanks, Anatoly