22/09/2021 10:03, Jerin Jacob:

On Wed, Sep 22, 2021 at 1:04 PM Thomas Monjalon [off-list ref] wrote:

quoted

21/09/2021 19:54, Jerin Jacob:

quoted

On Tue, Sep 21, 2021 at 11:00 PM Thomas Monjalon [off-list ref] wrote:

quoted

06/09/2021 06:17, jerinj@marvell.com:

quoted

It is handy to get detailed OOPS information like Linux kernel
when DPDK application crashes without losing any of the features
provided by coredump infrastructure by the OS.

This patch series introduces the APIs to handle OOPS in DPDK.

I don't understand how it is related to DPDK.

It abstracts the execution environment/architecture(See Arch Info in
log)[1] details to capture
details on fault handlers to enable additional details on fault from
DPDK application for
additional debugging information. Just like Kernel prints its OOPS on fault.

Not sure it is a good direction to achieve the same features as a kernel.

I just gave an example, that kernel has this feature and DPDK does not have it.
And it is good for DPDK applications.

Any specific point where you think this feature is not good for DPDK
in-tree and out of tree applications?

No specific. Just a fear we make life more complex for some users,
because there are always bugs and unplanned side effects.

quoted

In recent years, the idea was to make DPDK a focused library.

Not sure how this feature is not deviating from that. See below, on
libunwind library usage.

quoted

quoted

quoted

It looks something to be handled freely by the application
without DPDK forcing anything.

This NOT enforcing application to use DPDK OOPS handler, instead, if
registered then
it uses the default handler.

Even if the default handler is registered it invokes the application
handler if the application registers
the fault handler. So there is not difference in behavior.

OK

quoted

quoted

What is the benefit for other DPDK features?

Could you clarify this question a bit more?

I mean is it used by other parts of DPDK, or just a standalone feature?

Standalone feature in EAL. It can get a crash dump from any internal
library if it segfaults.
Default handler can be extended if we need more information specific
to DPDK libraries if need
(For example BPF etc)

quoted

quoted

quoted

Which problem is it solving?

Better debug trace on fault for DPDK application. Instead of faulting
with no information.

It does not look to be in the scope of DPDK, or I miss something.

I think it is, like we have APIs for creating control threads in EAL.

Also, This feature is dependent on libunwind as an optional dependency.
So we are not duplicating any other library effort just that integrating
all together including arch specific bits in EAL to have a feature for
better DPDK application usage.

That's a difficult decision. We need more opinions.
We may also discuss it in the techboard meeting today.