DPDK patches and discussions
 help / color / mirror / Atom feed
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: Morten Brørup <mb@smartsharesystems.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	techboard@dpdk.org, dev@dpdk.org,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	David Marchand <david.marchand@redhat.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [PATCH v1] gpudev: return EINVAL if invalid input pointer for free and unregister
Date: Thu, 9 Dec 2021 11:43:31 -0800
Message-ID: <20211209194331.GA26551@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86D4B@smartserver.smartshare.dk>

On Wed, Dec 08, 2021 at 07:40:10PM +0100, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Wednesday, 8 December 2021 18.35
> > 
> > On Fri, Dec 03, 2021 at 11:37:10AM +0100, Morten Brørup wrote:
> > > > From: Morten Brørup [mailto:mb@smartsharesystems.com]
> > > > Sent: Thursday, 2 December 2021 14.56
> > > >
> > > >
> > > > I disagree: Negative value does not mean failure. Only -1 means
> > > > failure.
> > > >
> > > > There is no -2 return value. There is no -EINVAL return value.
> > > >
> > > > Testing for (ret < 0) might confuse someone to think that other
> > values
> > > > than -1 could be returned as indication of failure, which is not
> > the
> > > > case when following the convention where the functions set errno
> > and
> > > > return -1 in case of failure.
> > > >
> > > > It would be different if following a convention where the functions
> > > > return -errno in case of failure. In this case, testing (ret < 0)
> > would
> > > > be appropriate.
> > > >
> > > > So explicitly testing (ret == -1) clarifies which of the two
> > > > conventions are relevant.
> > > >
> > >
> > > I tested it on Godbolt, and (ret < 0) produces slightly smaller code
> > than (ret == -1) on x86-64:
> > >
> > > https://godbolt.org/z/3xME3jxq8
> > >
> > > A binary test (Error or Data) uses 1 byte less, and a tristate test
> > (Error, Zero or Data) uses 3 byte less.
> > >
> > > Although there is no measurable performance difference for a single
> > instance of this kind of test, we should consider that this kind of
> > test appears many times in the code, so the saved bytes might add up to
> > something slightly significant in the instruction cache.
> > >
> > > My opinion is not so strong anymore... perhaps we should prefer
> > performance over code readability, also in this case?
> > >
> > 
> > i would not expect many calls that return rte_errno to be made on the
> > hot path. most of the use of errno / rte_errno is control but it's good
> > to have considered it. if i start seeing a lot of error handling in hot
> > paths i ordinarily find a way to get rid of it through various
> > techniques.
> 
> Tyler, I think you and I agree perfectly on this topic.
> 
> -1 should be returned as error, and rte_errno should provide details.
> 
> I'm only saying that comparing the return value with < 0 provides marginally less instruction bytes than comparing it with == -1, so even though -1 is the canonical indication of error, the comparison could be < 0 instead of == -1 (if weighing performance higher than code clarity).

sounds about right to me, i appreciate the extra analysis. certainly with
explicit -1 it doesn't stop an application gaining the slightly better
code generation with < 0.

thanks

  reply	other threads:[~2021-12-09 19:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-18 19:28 eagostini
2021-11-18 16:20 ` Stephen Hemminger
2021-11-18 16:22   ` Elena Agostini
2021-11-18 20:19 ` Tyler Retzlaff
2021-11-19  9:34   ` Ferruh Yigit
2021-11-19  9:56     ` Thomas Monjalon
2021-11-24 17:24       ` Tyler Retzlaff
2021-11-24 18:04         ` Bruce Richardson
2021-12-01 21:37           ` Tyler Retzlaff
2021-12-02  7:18             ` Thomas Monjalon
2021-12-02 12:33               ` Morten Brørup
2021-12-02 13:01                 ` Ananyev, Konstantin
2021-12-02 13:56                   ` Morten Brørup
2021-12-03 10:37                     ` Morten Brørup
2021-12-08 17:34                       ` Tyler Retzlaff
2021-12-08 18:40                         ` Morten Brørup
2021-12-09 19:43                           ` Tyler Retzlaff [this message]
2021-12-08 17:27                   ` Tyler Retzlaff
2021-11-19 10:15     ` Bruce Richardson
2021-11-18 20:33 ` [PATCH v2] gpudev: free and unregister return gracefully if input pointer is NULL eagostini
2021-11-22 18:24   ` [PATCH v3] gpudev: manage NULL pointer eagostini
2021-11-22 11:23     ` Thomas Monjalon
2021-11-22 11:34       ` Elena Agostini
2021-11-22 11:51         ` Thomas Monjalon
2021-11-22 23:52 ` [PATCH v4] " eagostini
2021-11-22 23:55 ` [PATCH v5] " eagostini
2021-11-22 16:01   ` Thomas Monjalon
2021-11-23  0:15 ` [PATCH v6] " eagostini
2021-11-23  0:42 ` [PATCH v7] " eagostini
2021-11-24  8:40   ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211209194331.GA26551@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
    --to=roretzla@linux.microsoft.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=mb@smartsharesystems.com \
    --cc=techboard@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ http://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git