[dpdk-dev] [PATCH v2 0/4] Introduce IF proxy library

[Jerin Jacob]

On Fri, Apr 10, 2020 at 3:33 PM Morten Brørup <mb at smartsharesystems.com> wrote:
>
> > From: Thomas Monjalon [mailto:thomas at monjalon.net]
> > Sent: Saturday, April 4, 2020 9:58 PM
> >
> > 04/04/2020 20:30, Andrzej Ostruszka [C]:
> > > Thomas,
> > >
> > > I have replied to the other mail, here I just want to confirm, that
> > I'm
> > > fine with the proposed "general messaging" which other libraries (IF
> > > Proxy including) could utilize.
> > >
> > > See also below.
> > >
> > > On 4/3/20 7:19 PM, Thomas Monjalon wrote:
> > > > 02/04/2020 15:48, Andrzej Ostruszka [C]:
> > > >> On 3/26/20 6:42 PM, Andrzej Ostruszka wrote:
> > > [...]
> > > >> Would that be easier/better to register queue together with a
> > bitmask of
> > > >> event types that given queue is accepting?  Than during setup
> > phase
> > > >> application would select just one queue to handle "global" events
> > and
> > > >> the logic of event handling for lcores should be simplier.
> > > >>
> > > >> Let me know what you think.
> > > >
> > > > I think we want to avoid complicate design.
> > > > So let's choose between callback and message queue.
> > > > I vote for message queue because it can handle any situation,
> > > > and it allows to control the context of the event processing.
> > > > The other reason is that I believe we need message queueing for
> > > > other purposes in DPDK (ex: multi-process, telemetry).
> > > >
> > > > You start thinking about complex message management.
> > > > And I start thinking about other usages of message queueing.
> > > > So I think it is the right time to introduce a generic messaging in
> > DPDK.
> > > > Note: the IPC rte_mp should be built on top of such generic
> > messaging.
> > >
> > > Do you have also inter-lcore communication in mind here?  Or just
> > > "external" world to "some DPDK controller/dispatcher" and how that is
> > > passed to other cores is an application writer problem.
> >
> > I was thinking at communication with:
> >       - DPDK event from random context
> >       - secondary process
> >       - external application
> >       - remote application
> >
> > In all cases, I thought the message receiver would be the master core.
>
> That would also be my assumption.

IMO, DPDK should not dictate that. The library can give API to for housekeeping.
It is up to the application to call on DPDK isolated cores or from the
control thread.
I think, we need to dictate only it should be used by a single consumer.