* [dpdk-dev] eventdev fault handling
@ 2020-01-07 7:17 Venky Venkatesh
0 siblings, 0 replies; only message in thread
From: Venky Venkatesh @ 2020-01-07 7:17 UTC (permalink / raw)
To: dev
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2020-01-07 7:17 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-07 7:17 [dpdk-dev] eventdev fault handling Venky Venkatesh
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).