From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9D86EA0C45; Wed, 22 Sep 2021 10:50:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 35CCF411A8; Wed, 22 Sep 2021 10:50:10 +0200 (CEST) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by mails.dpdk.org (Postfix) with ESMTP id C247D41196; Wed, 22 Sep 2021 10:50:08 +0200 (CEST) Received: by mail-il1-f181.google.com with SMTP id v16so1948159ilg.3; Wed, 22 Sep 2021 01:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=99hH6vGHAK8TRlDJC26M/qwwXCHLD0HO5W7LK6+114k=; b=RInr3gqOU00n2E0/W4Aj7Zm3q8tkdhEokB599OS7BfF0BQrHEhV6hUED8BRl0AD+iP 7xyaTiqOsqvey8yCa8qtbNvTW0a4zwz8GH+j1Rlw/I4Ja4KCOBSGZvzKvhtYjQ89Qr7z /degwnfwLEO1IYeFzC1qNngVy64GiiuN92Ta6Txxzt6hY4euLT/bN/QjJ+4RLjahL8UM GRlJKje+tyZKGPiH+8bsO2bMpVHbECfnoULwUsXUHmcCc/IZv+RQMaAdXIVpp1Ao3wuK 2nYh+VCTIbCVR6MCPCAl2ZQbcwT+NoGF3Bo+uJ52iMaItL72IbfrpiBngDp9tcrri4am 7w1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=99hH6vGHAK8TRlDJC26M/qwwXCHLD0HO5W7LK6+114k=; b=Ea0zuBZcQLr4An4ossSbVQDymXuHU0kRRr8+aEv8/ZE/mDsuBLDaG3yRgFB852G5tV rvIKGRbL7aI75jmBGDp88r4g3KVeY+2pKoQrVnBKs0JhqUlWKPRMh9gTgATYFObEHnec JSWNOS2YjjaqNEzpJn3qvE/RQWvLGyyRfXBBzqDAVB9SPp7d567f55BRP+AKM4uRbS9G XKS4V3qTcutbJmLf1UM6FD2f2eVNVMACEQegnEkLgmCHUduH4smmjE1qD/WPFquejc7Q MKr9N9T/MGg19U0XAvhezM37AFo2dusTSO0dY92AYaDI01qz1tP+JpZFjWj0y+X0FbzR MUfw== X-Gm-Message-State: AOAM532p7vtmH4MIkboxn/kgf3JVrbBemNFCHXMpFMSIf11FPO8xb5+F 9MHZOi0Dx0inzb+nBwwhjn3riXA+9YdVtOKj5hw= X-Google-Smtp-Source: ABdhPJyGzcXoPMbdze164t1KyrfunLtSLjhhoyHcnMJT2eW+1YtyEcSYHDme2yV5rCRta0IzmYd20bRWbJuvGesqGYY= X-Received: by 2002:a05:6e02:1b03:: with SMTP id i3mr6100191ilv.251.1632300608000; Wed, 22 Sep 2021 01:50:08 -0700 (PDT) MIME-Version: 1.0 References: <20210817032723.3997054-1-jerinj@marvell.com> <6691908.cbmxaGqiiQ@thomas> <11497238.xvjdXCvNTS@thomas> In-Reply-To: <11497238.xvjdXCvNTS@thomas> From: Jerin Jacob Date: Wed, 22 Sep 2021 14:19:41 +0530 Message-ID: To: Thomas Monjalon Cc: Jerin Jacob , dpdk-dev , David Marchand , "Richardson, Bruce" , Dmitry Kozlyuk , Narcisa Ana Maria Vasile , "Dmitry Malloy (MESHCHANINOV)" , Pallavi Kadam , "Ananyev, Konstantin" , "Ruifeng Wang (Arm Technology China)" , David Christensen , Stephen Hemminger , Olivier Matz , Ferruh Yigit , Andrew Rybchenko , Ajit Khaparde , =?UTF-8?Q?Morten_Br=C3=B8rup?= , techboard@dpdk.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 0/6] support oops handling X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Sep 22, 2021 at 2:03 PM Thomas Monjalon wrote: > > 22/09/2021 10:03, Jerin Jacob: > > On Wed, Sep 22, 2021 at 1:04 PM Thomas Monjalon wrote: > > > 21/09/2021 19:54, Jerin Jacob: > > > > On Tue, Sep 21, 2021 at 11:00 PM Thomas Monjalon wrote: > > > > > 06/09/2021 06:17, jerinj@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. > >