22/09/2021 10:03, Jerin Jacob: > 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?
No specific. Just a fear we make life more complex for some users, because there are always bugs and unplanned side effects. > > 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. That's a difficult decision. We need more opinions. We may also discuss it in the techboard meeting today.
