From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by dpdk.org (Postfix) with ESMTP id B79D8CF80 for ; Thu, 9 Mar 2017 16:49:23 +0100 (CET) Received: by mail-oi0-f41.google.com with SMTP id 62so38248451oih.2 for ; Thu, 09 Mar 2017 07:49:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qAjYcA4MllAZg8X3gEZ1tEdt3oOqrhlsQXTXlsFHO3A=; b=JJkzZTj4sXMdKpf9QwvIdL0Eivh+/SZWLFoAuVORMmvVDakklAp0EIs6+heqillGME GLrVagFMNZcuJHq3Ws8gy6DuR9335U6xEZph9Su49Tid2HZni/mCOS0MyLt4wNBuAnHA oLkRty01NVRUz0KuGj2LKFrbzGp8sqPV//7v7DO2854ERtwq9VA2IeITGwGGacZMNWJQ 1vtVXtLFVA/BL+Zrm9gndyaviEAdg2bhV0ck3r+dK9kFtGyk5dZ/NNJW4z6b2y7L6jxT sGBzhNt442aECnNzNUk7qBNC2xyt0FTrXpEqAqm7CHHEjcIrlCuY0dzT55RJxjCUukDK Y5kg== X-Gm-Message-State: AMke39ma35UOH3QDzzXZB/qal6MNhFPoZ9M4Vc2ogd0u6Dj8yCDDe6bIOT6NNRyHjN79HpBRKJNBKnWMPAkBEt30 X-Received: by 10.202.218.134 with SMTP id r128mr6238556oig.2.1489074562618; Thu, 09 Mar 2017 07:49:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.198.1 with HTTP; Thu, 9 Mar 2017 07:49:22 -0800 (PST) In-Reply-To: <1673691.cTdATcOVfP@xps13> References: <20170123211340.22570-1-bmcfall@redhat.com> <2417966.3G0haXHz4n@xps13> <1673691.cTdATcOVfP@xps13> From: Billy McFall Date: Thu, 9 Mar 2017 10:49:22 -0500 Message-ID: To: Thomas Monjalon Cc: wenzhuo.lu@intel.com, olivier.matz@6wind.com, dev@dpdk.org, adrien.mazarguil@6wind.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v5 1/3] ethdev: new API to free consumed buffers in Tx ring 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: Thu, 09 Mar 2017 15:49:24 -0000 On Tue, Mar 7, 2017 at 11:03 AM, Thomas Monjalon wrote: > 2017-03-07 09:29, Billy McFall: > > On Mon, Feb 27, 2017 at 8:48 AM, Thomas Monjalon < > thomas.monjalon@6wind.com> > > wrote: > > > I think you could use rte_errno (while keeping negative return codes). > > > > > > > I can do that if you want, but if I understand your comment, it will make > > the implementation of the function not as clean. I cannot use the > existing > > RTE_ETH_VALID_PORTID_OR_ERR_RET(..) and RTE_FUNC_PTR_OR_ERR_RET(..) > MACROs > > because they are handling the return on error. Or am I missing something? > > Yes. Maybe we need new macros for basic error management with rte_errno. > > Looking at the code. Do you think we need new MACROs or just set rte_errno in the existing? What would be the down side to setting rte_errno for all the existing calls? Looks like RTE_ETH_VALID_PORTID_OR_ERR_RET(..) is being called ~135 times. Most calls are with retval set to either -ENODEV or -EINVAL. A few instances of 0 and -1, but not many. Looks like RTE_FUNC_PTR_OR_ERR_RET(..) is being called ~100 times. Most calls are with retval set to -ENOTSUP. A few instances of 0, but not many. I was thinking: /* Macros to check for valid port */ #define RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, retval) do { \ if (!rte_eth_dev_is_valid_port(port_id)) { \ RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id); \ + if (retval < 0) \ + rte_errno = -retval; \ return retval; \ } \ } while (0) Thanks, Billy