From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com [209.85.192.180]) by dpdk.org (Postfix) with ESMTP id ED114B6D for ; Tue, 31 Jan 2017 17:57:04 +0100 (CET) Received: by mail-pf0-f180.google.com with SMTP id 189so108567199pfu.3 for ; Tue, 31 Jan 2017 08:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=FH2NI0UWpiV4iRWoTmXNZ9uuAO5zitppm+eOspTbCUk=; b=HXbMxz59/kb3uzQT9KwOa4Ug9h303abQatggW0Sy/o/At2puVX2rxSp/aVjUpW23rh C0VjkSp1dGA2GdDb0QEW1e0xrRD5PGIs9u+I9tvePuIHgmj7WAUyx9zb/lHSaKRI6ppa SXm9prY5e6aA4vxCK/Tewml3rPxJDJbDLi8V/CgnmVcWBEIVgvXD+0Mon9ZwlwBsY1IO ks4QLGrFkJJwBXg+vcuFXz2NefLn0011TFoMsKmRrJ92EdEb10VN4Gk54wr/Zj+6U3bb 9GlJjjW5jJGmaJsQRz+PzNFfYeU9Lr5sF8HnmKUhfRK5Y75hA+I4yBle4Z6sgQtkczy8 vQzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=FH2NI0UWpiV4iRWoTmXNZ9uuAO5zitppm+eOspTbCUk=; b=Jx2ZZqegeuq9JhHh4jLNLitbsdwva81O/XZL8fV4Uv4IqaB4ig2aVHaC0qgl2GoA+O bJyh2Wgbn2KbLooqHNOiL8au090wVTmPniajwnq/8rlTcnmH3SyEdV4zD+eLmhN+Km+8 6nh6LS7XV96/AZCRw2ulAXb2noy2MeXY09F4GXFCt1j56Xy27Sn/LJdk4dFLiCrH8VeN rAcHv+fiDS86o2csYA7s3wnFOAQgR3wajYN1z3+wQk3fhoEtCkBNbZudg9vAfeq6D2v0 IW1loY/Bglz+A9HLNeo/tXeKojlzv2a/dvUJ293+golGvO+R6V0nuxbuXYvOHRft4rIV MFRA== X-Gm-Message-State: AIkVDXJFnJKe/YVYelflDQqHuu37aae04jkJs5MYlL1edoPikEJsAI2qmx7kIIk0ZPHd2w== X-Received: by 10.99.241.17 with SMTP id f17mr31298516pgi.94.1485881824207; Tue, 31 Jan 2017 08:57:04 -0800 (PST) Received: from xeon-e3 (204-195-18-65.wavecable.com. [204.195.18.65]) by smtp.gmail.com with ESMTPSA id z127sm27799940pgz.29.2017.01.31.08.57.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 31 Jan 2017 08:57:03 -0800 (PST) Date: Tue, 31 Jan 2017 08:56:57 -0800 From: Stephen Hemminger To: Bruce Richardson Cc: Aaron Conole , dev@dpdk.org Message-ID: <20170131085657.4c396dcd@xeon-e3> In-Reply-To: <20170131093345.GA119364@bricha3-MOBL3.ger.corp.intel.com> References: <1485529023-5486-1-git-send-email-aconole@redhat.com> <1485529023-5486-26-git-send-email-aconole@redhat.com> <20170127083346.2bf55801@xeon-e3> <20170127164739.GB82692@bricha3-MOBL3.ger.corp.intel.com> <20170127093729.5cef9138@xeon-e3> <20170131093345.GA119364@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 25/25] rte_eal_init: add info about rte_errno codes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 16:57:05 -0000 On Tue, 31 Jan 2017 09:33:45 +0000 Bruce Richardson wrote: > On Mon, Jan 30, 2017 at 01:38:00PM -0500, Aaron Conole wrote: > > Stephen Hemminger writes: > > > > > On Fri, 27 Jan 2017 16:47:40 +0000 > > > Bruce Richardson wrote: > > > > > >> On Fri, Jan 27, 2017 at 08:33:46AM -0800, Stephen Hemminger wrote: > > >> > On Fri, 27 Jan 2017 09:57:03 -0500 > > >> > Aaron Conole wrote: > > >> > > > >> > > diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h > > >> > > index 03fee50..46e427f 100644 > > >> > > --- a/lib/librte_eal/common/include/rte_eal.h > > >> > > +++ b/lib/librte_eal/common/include/rte_eal.h > > >> > > @@ -159,7 +159,29 @@ int rte_eal_iopl_init(void); > > >> > > * function call and should not be further interpreted by the > > >> > > * application. The EAL does not take any ownership of the memory used > > >> > > * for either the argv array, or its members. > > >> > > - * - On failure, a negative error value. > > >> > > + * - On failure, -1 and rte_errno is set to a value indicating the cause > > >> > > + * for failure. > > >> > > + * > > >> > > + * The error codes returned via rte_errno: > > >> > > + * EACCES indicates a permissions issue. > > >> > > + * > > >> > > + * EAGAIN indicates either a bus or system resource was not available, > > >> > > + * try again. > > >> > > + * > > >> > > + * EALREADY indicates that the rte_eal_init function has already been > > >> > > + * called, and cannot be called again. > > >> > > + * > > >> > > + * EINVAL indicates invalid parameters were passed as argv/argc. > > >> > > + * > > >> > > + * EIO indicates failure to setup the logging handlers. This is usually > > >> > > + * caused by an out-of-memory condition. > > >> > > + * > > >> > > + * ENODEV indicates memory setup issues. > > >> > > + * > > >> > > + * ENOTSUP indicates that the EAL cannot initialize on this system. > > >> > > + * > > >> > > + * EUNATCH indicates that the PCI bus is either not present, or is not > > >> > > + * readable by the eal. > > >> > > */ > > >> > > int rte_eal_init(int argc, char **argv); > > >> > > > >> > Why use rte_errno? > > >> > Most DPDK calls just return negative value on error which > > >> > corresponds to error number. > > >> > Are you trying to keep ABI compatibility? Doesn't make sense > > >> > because before all these > > >> > errors were panic's no working application is going to care. > > >> > > >> Either will work, but I actually prefer this way. I view using rte_errno > > >> to be better as it can work in just about all cases, including with > > >> functions which return pointers. This allows you to have a standard > > >> method across all functions for returning error codes, and it only > > >> requires a single sentinal value to indicate error, rather than using a > > >> whole range of values. > > > > > > The problem is DPDK is getting more inconsistent on how this is done. > > > As long as error returns are always same as kernel/glibc errno's it really doesn't > > > matter much which way the value is returned from a technical point of view > > > but the inconsistency is sure to be a usability problem and source of errors. > > > > I am using rte_errno here because I assumed it was the preferred > > method. In fact, looking at some recently contributed modules (for > > instance pdump), it seems that folks are using it. > > > > I'm not really sure the purpose of having rte_errno if it isn't used, so > > it'd be helpful to know if there's some consensus on reflecting errors > > via this variable, or on returning error codes. Whichever is the more > > consistent with the way the DPDK project does things, I'm game :). > > > Unfortunately, this is one area where DPDK is inconsistent, and both > schemes are widely used. I much prefer using the rte_errno method, but > returning error codes directly is also common in DPDK. One argument in favor of returning error codes directly, is that it makes it safer in application when one user function is returning an error code back through its internal call tree. Also, the API does not really do a good job of distinguishing between normal (no data present) and exceptional (NIC has died). At least it doesn't depend on something like Structured Exception handling... Feel free to clean the stables on this one.