[dpdk-dev] [PATCH v6 1/2] eal: add channel for multi-process communication

Burakov, Anatoly anatoly.burakov at intel.com
Mon Jan 29 10:37:47 CET 2018


On 29-Jan-18 6:37 AM, Tan, Jianfeng wrote:
> Hi Anatoly,
> 
>> -----Original Message-----
>> From: Burakov, Anatoly
>> Sent: Friday, January 26, 2018 6:26 PM
>> To: Tan, Jianfeng; dev at dpdk.org
>> Cc: Richardson, Bruce; Ananyev, Konstantin; thomas at monjalon.net
>> Subject: Re: [PATCH v6 1/2] eal: add channel for multi-process
>> communication
>>
>> On 26-Jan-18 3:41 AM, Jianfeng Tan wrote:
>>> Previouly, there are three channels for multi-process
>>> (i.e., primary/secondary) communication.
>>>     1. Config-file based channel, in which, the primary process writes
>>>        info into a pre-defined config file, and the secondary process
>>>        reads the info out.
>>>     2. vfio submodule has its own channel based on unix socket for the
>>>        secondary process to get container fd and group fd from the
>>>        primary process.
>>>     3. pdump submodule also has its own channel based on unix socket for
>>>        packet dump.
>>>
>>> It'd be good to have a generic communication channel for multi-process
>>> communication to accommodate the requirements including:
>>>     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.
>>>     d. A send message request needs the other side to response immediately.
>>>
>>> This patch proposes to create a communication channel, based on
>> datagram
>>> unix socket, for above requirements. Each process will block on a unix
>>> socket waiting for messages from the peers.
>>>
>>> Three new APIs are added:
>>>
>>>     1. rte_eal_mp_action_register() is used to register an action,
>>>        indexed by a string, when a component at receiver side would like
>>>        to response the messages from the peer processe.
>>>     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, and returns
>>>        immediately. If there are n secondary processes, the primary
>>>        process will send n messages.
>>>
>>> Suggested-by: Konstantin Ananyev <konstantin.ananyev at intel.com>
>>> Signed-off-by: Jianfeng Tan <jianfeng.tan at intel.com>
>>> Reviewed-by: Anatoly Burakov <anatoly.burakov at intel.com>
>>> Acked-by: Konstantin Ananyev <konstantin.ananyev at intel.com>
>>> ---
>>> +	}
>>> +	closedir(mp_dir);
>>> +
>>> +	return ret;
>>
>> Nitpick: you probably don't need ret here, just return 0 as in other places.
> 
> We cannot just return 0 as it could be -1 as above comment shows.
> The ret variable was introduced to avoid two "closedir()".
> 
> Thanks,
> Jianfeng
> 

Yep you're right, apologies.

-- 
Thanks,
Anatoly


More information about the dev mailing list