[dpdk-dev] [PATCH v2 07/12] eal: add channel for primary/secondary communication

Tan, Jianfeng jianfeng.tan at intel.com
Sat Sep 30 06:07:50 CEST 2017



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 at dpdk.org] On Behalf Of Burakov, Anatoly
>>> Sent: Thursday, September 28, 2017 11:30 PM
>>> To: dev at 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 at dpdk.org
>>>>> Cc: Richardson, Bruce <bruce.richardson at intel.com>; Ananyev,
>>> Konstantin <konstantin.ananyev at intel.com>; De Lara Guarch, Pablo
>>>>> <pablo.de.lara.guarch at intel.com>; thomas at monjalon.net;
>>> yliu at fridaylinux.org; maxime.coquelin at redhat.com; mtetsuyah at gmail.com;
>>>>> Yigit, Ferruh <ferruh.yigit at intel.com>; Tan, Jianfeng
>>> <jianfeng.tan at intel.com>
>>>>> 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


More information about the dev mailing list