On Wed, Sep 22, 2021 at 1:04 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > 21/09/2021 19:54, Jerin Jacob: > > On Tue, Sep 21, 2021 at 11:00 PM Thomas Monjalon <tho...@monjalon.net> > > wrote: > > > > > > 06/09/2021 06:17, jer...@marvell.com: > > > > 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? > 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. > > > > 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 > > > > 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) > > > > 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. > >
