Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability

[David Marchand <david.marchand@redhat.com>]

On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@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.burakov@intel.com <mailto:anatoly.burakov@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 ?


-- 
David Marchand