From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2017 03:09:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,468,1500966000"; d="scan'208";a="905813355" Received: from aburakov-mobl2.ger.corp.intel.com (HELO [10.237.210.130]) ([10.237.210.130]) by FMSMGA003.fm.intel.com with ESMTP; 02 Oct 2017 03:08:59 -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> <992217df-6bfb-063c-e3e6-11930c5108da@intel.com> From: "Burakov, Anatoly" Message-ID: <9ebf5003-ee17-df40-2344-fb6366a94b9a@intel.com> Date: Mon, 2 Oct 2017 11:08:58 +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: 8bit 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: Mon, 02 Oct 2017 10:09:03 -0000 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