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

[Tan, Jianfeng]

Hi Jan,

> -----Original Message-----
> From: jblunck at gmail.com [mailto:jblunck at gmail.com] On Behalf Of Jan
> Blunck
> Sent: Thursday, October 5, 2017 8:02 PM
> To: Tan, Jianfeng
> Cc: dev; Richardson, Bruce; Ananyev, Konstantin; De Lara Guarch, Pablo;
> Thomas Monjalon; yliu at fridaylinux.org; Maxime Coquelin; Tetsuya Mukawa;
> Yigit, Ferruh
> Subject: Re: [dpdk-dev] [PATCH v2 07/12] eal: add channel for
> primary/secondary communication
> 
> On Thu, Sep 28, 2017 at 3:55 PM, Jianfeng Tan <jianfeng.tan at intel.com>
> wrote:
> > 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.
> >
> 
> Sorry, but I fail to see how this is something that should be solved
> in the DPDK. This is about application interprocess communication.
> From my point of view this has absolutely nothing to do with the DPDK.

IMO, it's a refinement of current primary/secondary model. (BTW, the primary/secondary model is inherent in DPDK at very early stage, and proved to be useful for application design)

And as previous reviewers point out, there are already some mechanisms in each component (eal init, vfio, pdump) to do the primary/secondary communication. This patch is targeted to converge them into one generic mechanism.

In the other side, we don't want the applications developers to take care of the communication information inside DPDK library, right?

> 
> From my point of view the DPDK should not become another operating
> system abstraction library outside of what is absolutely required. We
> already dictate way too much (e.g. threading model, config files, ...)
> for the users of the DPDK.

I agree in some extent. But for threading model, we do have the use cases, like quick restart, fault isolation,etc.

Thanks,
Jianfeng