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-boun...@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 <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.
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
