[dpdk-dev] [PATCH] eventdev: fix device probe and remove for secondary process
Jerin Jacob
jerinjacobk at gmail.com
Sun May 3 11:58:06 CEST 2020
On Sun, May 3, 2020 at 6:45 AM Varghese, Vipin <vipin.varghese at intel.com> wrote:
>
> Hi Pavan,
>
> Snipped
>
> > >> > >
> > >> > > When probing event device in secondary process skip
> > >> > > reinitializing the device data structure as it is already done in primary
> > process.
> > >> > >
> > >> > > When removing event device in secondary process skip closing the
> > >> > > event device as it should be done by primary process.
> > >If primary has crashed or closed before secondary abnormally. Should
> > >not close of secondary trigger removal of Eventdev services?
> >
> > Closing event device on exit of one secondary doesn’t make sense as there
> > might be systems where there might be one primary and multiple secondaries
> > and secondaries are spawned/destroyed on demand.
> >
> > Behavior of secondaries on primary process crash is undefined.
> Absolutely true, there are work scenarios where primary configures ports and Eventdev queues-ports pair. It would be multiple secondaries which process packets via event dev. In such cases, when primary segfaults or crashes it will lead to undefined states.
>
> In such scenarios, would not it be preferer able for all secondaries to subscribe to service function like health check. If the primary is not alive anymore, then gracefully handle inflight events and events to dequeue. If this is right understanding, should not there be option in secondary to gracefully shut down it's worker queue and ports (rather than event device instance)?
The health check function may not be limited to eventdev, it must
apply for all the subsystems in multiprocess mode if primary dies.
Such features can be designed/agreed based on every subsystem in mind.
For rc2, Let's have this bug fix. New features can be implemented
after an agreement with all stakeholders wrt multi-process semantics
which applicable for all subsystems.
>
> snipped
More information about the dev
mailing list