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 A80E3A0C45; Wed, 22 Sep 2021 10:33:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8CE4841198; Wed, 22 Sep 2021 10:33:24 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id 7BA4A41196; Wed, 22 Sep 2021 10:33:23 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 010CC58052F; Wed, 22 Sep 2021 04:33:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 22 Sep 2021 04:33:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= /7e7p4HJsZDnsIiTiXI1FFPGXkrbCOgq/PGEb8ZRHWA=; b=ESEs2773jhuyfUb8 0VGV4hUwnHkawZMqMknLLkP51Y75DOzQ0JwZA6hjFAiExFXAPl4ngaD7CuZ4Wi1+ vDbPF9ZjRNWaBPlmdYYnBW65lixetupkWkHM+tUUf1ZUrz4upAnsYEZR1cTt+AtF buJbsEl3v1A5Xay8JnmjstziyvnrKyQJLnHAexqmJ35xDsFA5VOB0PMZKu4wfNeu b4WkCAW3WUG56lDpLVf8UOewoajbpVVtVM5hJ0bPyuAFqXmIaIbAKtAY2KsdN2Hf ZvR/sZrb/FOm6X8YAzAYKFwV0iGOM3bgzJ8gRBwA1isy3dOZrKMS+9/rbtNy7SCE 2TyoKw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=/7e7p4HJsZDnsIiTiXI1FFPGXkrbCOgq/PGEb8ZRH WA=; b=ONpMkElZ02y8O8fvP1ma7Cf87Wvq1vrcF+PX5TFvmbl5ejDK7h7ad3W/e FQT+9HM8fFfjZ/T/CF3YPwEBto1JimLaRtLUfTTDGIZ0A/4lONf4Ai6tHdgbrv5g bwvkaDj+7ZqEpWmdb72vPiOEuPhK3PHE2WXRdsF0AIwtuuJB/6Rk5+rs+MlLxlim gr5kokFGlqjbm3Ms5yjz2lGYY/FBBKTEltVK/gEqmrFPs04TGbZFHSCt049wvJsx wXHyVYDOcB2ONMBzy1gv1gSDPuijmLfprau4PYfq4XxEuQBjXHLCGmbLPyN0fM5G fCfYby6RWJYQ3VzCRukPkGHg5wz4g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudeijedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 22 Sep 2021 04:33:19 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: dev@dpdk.org, 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 , Morten =?ISO-8859-1?Q?Br=F8rup?= , Jerin Jacob , techboard@dpdk.org Date: Wed, 22 Sep 2021 10:33:16 +0200 Message-ID: <11497238.xvjdXCvNTS@thomas> In-Reply-To: References: <20210817032723.3997054-1-jerinj@marvell.com> <6691908.cbmxaGqiiQ@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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. > > 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.