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 96920A0C45; Wed, 22 Sep 2021 10:03:50 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 79C8241198; Wed, 22 Sep 2021 10:03:50 +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 3498A41196 for ; Wed, 22 Sep 2021 10:03:49 +0200 (CEST) Received: by mail-il1-f181.google.com with SMTP id b8so1768175ilh.12 for ; Wed, 22 Sep 2021 01:03:49 -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=w2Nofrjw7x80rP2XCJD4mchtpv/izZ1KvR/xQqafqgY=; b=pAec25Varmm9LGapeb4tsYBUlToM3I9E5yaInyeBDJAnVvCuDkCT0J2oza6sUfVBGl 2bcP1XHP69CAvXQR/e+fX0UsGsKKNBtLi0FhkT8PxJ5X9hkdMpkkw4Z6o1tNulnM1HGK l1QOidlQmBy4Jy89iTaWhEtLMd76om77N93j6hGGL2yFuJat+9Puj6YBIgdtmcPpZxHR KOuHlFUdjD41228zAOsYeCEn3y4rC92ejvsLTjBmpVpvy44W7SNUEcsNpizaJLEdClbU bWlx2I7Y8Aq4zxeD0iiyot0KzpxA/9HIIgs33SDn5jp5atYJszBn0324G/KTRMKOfyQe vEOQ== 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=w2Nofrjw7x80rP2XCJD4mchtpv/izZ1KvR/xQqafqgY=; b=pKjyCQXBJ/37k/mXG8ARGIRCkx2GLiTZFK/W/7AdRX94ObdiP9IhA6cQ9IcQ55v3LD 8tfmWbZRHw4rfVrX64mhL+CGG9TwLwefRKxdm12pHg4vIJQZ6cYStFepKBLpQ7ahwJqn ql1TgzQVC625vdEEywA5h+aZcHQGNmE6cQ2i8B7X/+dJHoOcEq0+eW1XaH9Ow9ZSsi/k 3wpC4V7vP0ZIZegzhBPD7MLFQ6glO/jhcq9a1+gAejWNfXIzEq33EeJUiZhGMIswTlVx Of/9prsj43e26CQlyhb6+X4kGBsAOtMembEiGLY7VhIL070GepMLcXMYWROSv50js98d TB3w== X-Gm-Message-State: AOAM530QoHzIJ/ovSZGeMEvI11NnUf97q4PLDYrFgaBllJSNE1DNSvIT ZFWDhe5hFiIxDEwgqPF9ydP4s1pARacr08CsZ9U= X-Google-Smtp-Source: ABdhPJx6W65z71N+8S3VU/fPKQjesUGsyv9Sughg+sHzxT8/oxIoiqH+8o5eCyPSjUKehgYGHhuffWs+018daKBvwFc= X-Received: by 2002:a92:ca06:: with SMTP id j6mr7534878ils.243.1632297828300; Wed, 22 Sep 2021 01:03:48 -0700 (PDT) MIME-Version: 1.0 References: <20210817032723.3997054-1-jerinj@marvell.com> <7007516.EuRbNVrdOy@thomas> <6691908.cbmxaGqiiQ@thomas> In-Reply-To: <6691908.cbmxaGqiiQ@thomas> From: Jerin Jacob Date: Wed, 22 Sep 2021 13:33:22 +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?= 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 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? > 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. > >