[dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
Stephen Hemminger
stephen at networkplumber.org
Mon Apr 8 17:13:36 CEST 2019
On Mon, 8 Apr 2019 16:38:55 +0200
David Marchand <david.marchand at redhat.com> wrote:
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov at 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 at intel.com <mailto:anatoly.burakov at 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.
More information about the dev
mailing list