DPDK patches and discussions
 help / color / mirror / Atom feed
From: Venky Venkatesh <vvenkatesh@paloaltonetworks.com>
To: dev@dpdk.org
Subject: [dpdk-dev] eventdev fault handling
Date: Mon, 6 Jan 2020 23:17:16 -0800	[thread overview]
Message-ID: <CAJ4WCtJzgXzLHeWuOTt_eoEps897Apxmkmw0VAmK+dzJ1qBjaw@mail.gmail.com> (raw)

Hi,
This concerns eventdev being used in a DPDK multi-process mode wherein the
PRIMARY process sets up the device, ports, queues and linkages and the
SECONDARY processes are the real workers to which the events are load
balanced to via the queues.

My question (for both the sw evdev PMD and the DSW evdev PMD) is what is
the recommended handling when one of the SECONDARY processes dies? In
answering this you can assume that the dead process will be restarted in a
few seconds (within 10 seconds):

   1. Is it worthwhile unlinking that process from the queues it is linked
   to?
   2.  If so, do these PMDs support such capabilities? Additionally, what
   is to be done with (i.e. with respect to telling the eventdev) the events
   queued to the concerned core but not dequeued AND the burst dequeued held
   by the process at the time of death?
   3. If not, then if there is continuous traffic bound to that process
   (for reasons e.g. scheduling algorithm of the PMD, flowid state while dying
   etc.), will the device eventually get backed up due to max-inflight? If so,
   what is the recommended remedy?
   4. For DSW there is the additional aspect of ongoing/future migrations
   -- what is the design recommendation to compensate for that during a
   process crash

If your answer is sensitive to the restart delay, pls explain for the
different delay ranges.

Thanks
-Venky

                 reply	other threads:[~2020-01-07  7:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=CAJ4WCtJzgXzLHeWuOTt_eoEps897Apxmkmw0VAmK+dzJ1qBjaw@mail.gmail.com \
    --to=vvenkatesh@paloaltonetworks.com \
    --cc=dev@dpdk.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).