All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Varghese, Vipin" <vipin.varghese@intel.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>,
	"Jerin Jacob Kollanukkaran" <jerinj@marvell.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	dpdk-dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] eventdev: fix device probe and remove for secondary process
Date: Sun, 3 May 2020 12:57:39 +0000	[thread overview]
Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D4BBC8D@BGSMSX101.gar.corp.intel.com> (raw)
In-Reply-To: <CALBAE1P8srBgWgHv1kieuZPBkRsbF3Sv_uUCiuG3o-SDj+Bmqw@mail.gmail.com>

Thanks Jerin, agree with you on graceful shutdown in rc2.

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Sunday, May 3, 2020 3:28 PM
> To: Varghese, Vipin <vipin.varghese@intel.com>
> Cc: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Jerin Jacob
> Kollanukkaran <jerinj@marvell.com>; Burakov, Anatoly
> <anatoly.burakov@intel.com>; dpdk-dev <dev@dpdk.org>
> Subject: Re: [dpdk-dev] [PATCH] eventdev: fix device probe and remove for
> secondary process
> 
> On Sun, May 3, 2020 at 6:45 AM Varghese, Vipin <vipin.varghese@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

      reply	other threads:[~2020-05-03 12:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 18:10 [dpdk-dev] [PATCH] eventdev: fix device probe and remove for secondary process pbhagavatula
2020-05-01 13:26 ` Jerin Jacob
2020-05-02 10:31   ` Jerin Jacob
2020-05-02 12:07     ` Varghese, Vipin
2020-05-02 13:04       ` Pavan Nikhilesh Bhagavatula
2020-05-03  1:15         ` Varghese, Vipin
2020-05-03  9:58           ` Jerin Jacob
2020-05-03 12:57             ` Varghese, Vipin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C9E0AB70F954A408CC4ADDBF0F8FA7D4D4BBC8D@BGSMSX101.gar.corp.intel.com \
    --to=vipin.varghese@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=pbhagavatula@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.