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 <bruce.richard...@intel.com>; Ananyev, Konstantin <konstantin.anan...@intel.com>; De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>; tho...@monjalon.net; y...@fridaylinux.org; maxime.coque...@redhat.com; mtetsu...@gmail.com; Yigit, Ferruh <ferruh.yi...@intel.com>; Tan, Jianfeng <jianfeng....@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. 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.
-- Thanks, Anatoly
