On Mon, 8 Apr 2019 16:38:55 +0200 David Marchand <david.march...@redhat.com> wrote:
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.bura...@intel.com> > wrote: > > > On 08-Apr-19 2:58 PM, David Marchand wrote: > > > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly > > > <anatoly.bura...@intel.com <mailto:anatoly.bura...@intel.com>> wrote: > > > > > > As a concrete proposal, my number one dream would be to see > > > multiprocess > > > gone. I also recall desire for "DPDK to be more lightweight", and i > > > maintain that DPDK *cannot* be lightweight if we are to support > > > multiprocess - we can have one or the other, but not both. However, > > > realistically, i don't think dropping multiprocess is ever going to > > > happen - not only it is too entrenched in DPDK use cases, it is > > > actually > > > quite useful despite its flaws. > > > > > > > > > Well, honestly, I'd like to hear about this. > > > What are the real usecases for multi process support? > > > Do we have even a single opensource project that uses it? > > > > > > > I'm aware of a few closed source usages of multiprocess. I also think > > current versions of collectd rely on secondary process (there's been a > > Telemetry API added to avoid that, but AFAIK the support for Telemetry > > is not upstream in collectd yet), and so do/would any dump-style > > applications - in fact, we ourselves include one such application in our > > codebase (pdump, proc-info, etc.). > > > > Sorry, I don't want to highjack this thread, I can start a separate thread > if people feel like it. > If we go with stabilisation, we must be careful that we want to support the > features. > > So about multiprocess, again, in those closed source projects you know of, > what are the usecases? > > For what we provide in dpdk pdump, proc-info, referring to oneself is not > that convincing to me as I don't use those tools. > > I don't see what we could not achieve the same with a control thread > running in the dpdk process and handling commands. > It would be open to the outside via a more standard channel, like a UNIX > socket or something like this. > If we need to declare a dynamic channel, it can be constructed as an > extension of the existing standard channel: we can open something like a > POSIX shm and push things in it. > Was this explored ? > > Yes, there are several closed source applications using multi-process. But the problem with that is no one tests with all the drivers, api's and configurations in DPDK.
