On Wed, Sep 22, 2021 at 2:03 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > 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.
OK. That's more of a non technical thing. I have provided an EAL switch to disable this feature like telemetry has a disable option as EAL argument. It can be used for this purpose. > > > > 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. Sure. > We may also discuss it in the techboard meeting today. Sure. > >
