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 75E0DA034E; Sun, 6 Feb 2022 04:45:15 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 408664069D; Sun, 6 Feb 2022 04:45:15 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 1613140042 for ; Sun, 6 Feb 2022 04:45:14 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 5C31520B8013; Sat, 5 Feb 2022 19:45:13 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 5C31520B8013 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1644119113; bh=ji5p3N2ilVPNqOkwES3Lv8jpvCLeQyhBCMG9gTAe6/A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EXZK/yfNK+QQ+se6f97VRIxrkEvkwSoppP/LySCMYxDW7DCzM9TJ/f54HM2KQ+QiX Cn9v5qjGXxmiF4k/7V+DUqiFO96SS87KM1zI0/4nVuisKenkhsKdq9xh3vIYE19rBn 2sDe0PO7MWghfJz+OgLyxi60suWGH6hLLo9rMaB8= Date: Sat, 5 Feb 2022 19:45:13 -0800 From: Tyler Retzlaff To: Thomas Monjalon Cc: "Ananyev, Konstantin" , "navasile@linux.microsoft.com" , "Richardson, Bruce" , "david.marchand@redhat.com" , "dev@dpdk.org" , "dmitry.kozliuk@gmail.com" , "dmitrym@microsoft.com" , "khot@microsoft.com" , "navasile@microsoft.com" , "ocardona@microsoft.com" , "Kadam, Pallavi" , "roretzla@microsoft.com" , "talshn@nvidia.com" Subject: Re: [PATCH v18 2/8] eal: add thread attributes Message-ID: <20220206034513.GA4118@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20220205044140.GA7734@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <7543187.gsGJI6kyIV@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7543187.gsGJI6kyIV@thomas> User-Agent: Mutt/1.5.21 (2010-09-15) 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 On Sat, Feb 05, 2022 at 10:00:01AM +0100, Thomas Monjalon wrote: > 05/02/2022 05:41, Tyler Retzlaff: > > On Fri, Feb 04, 2022 at 07:21:10PM +0000, Ananyev, Konstantin wrote: > > > > +int > > > > +rte_thread_attr_init(rte_thread_attr_t *attr) > > > > +{ > > > > + RTE_VERIFY(attr != NULL); > > > > > > As a generic one, here and everywhere: > > > Please don't use RTE_VERIFY() for checking input function parameters. > > > We don't want to panic in case of just invalid parameter from user. > > > > i ask this question again. what useful thing will the user application > > do when handling -EINVAL or rte_errno = EINVAL is returned for > > incorrectly supplied parameters? > > > > again, there should be a mechanism that allows a policy for how these > > non-recoverable errors are handled rather than defaulting to tossing > > it over the fence and expecting the application to do something > > sensible when the only thing it could do is conclusively more > > complicated than having passed the correct parameters in the first place. > > > > more often then not application programmers will ignore superfluous > > return values from functions like this resulting in the bug remaining > > longer and the state / reason being lost. > > > > please reconsider. > > The application should just abort this feature indeed. > But remember the application can have other features. > In some applications, the DPDK features are a minor part. > So we don't want to crash the entire application just because > a DPDK feature has a bug. > More generally, a library should never crash an entire application. > > you haven't addressed my concern. when deployed at scale i need to be able to capture the state of what was wrong in order to debug the problem. a crash dump does this. i agree that the dpdk functionality may be shared/hosted in a process that does other work but this api hard-codes a behavior that does not permit easy diagnostics of buggy usage of api vs actual errors. there is a distinction and it is important. with the api hard-coded to a single policy you leave the application author only the option of wrapping every single api in some boilerplate error handling logic that has to teadeously log part of the application state (hopefully the part you need) from the current scope before explicitly exiting. as i explained previously i'm not asking that dpdk hard-codes a policy of crashing either. we just need it to be a choice rather than forcing a single hard-coded behavior.