DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Thomas Monjalon" <thomas@monjalon.net>,
	"Tyler Retzlaff" <roretzla@linux.microsoft.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>
Cc: <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: Fri, 3 Dec 2021 11:37:10 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86D35@smartserver.smartshare.dk> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86D34@smartserver.smartshare.dk>

> From: Morten Brørup [mailto:mb@smartsharesystems.com]
> Sent: Thursday, 2 December 2021 14.56
> 
> > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
> > Sent: Thursday, 2 December 2021 14.01
> >
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > Sent: Thursday, 2 December 2021 08.19
> > > >
> > > > 01/12/2021 22:37, Tyler Retzlaff:
> > > > > On Wed, Nov 24, 2021 at 06:04:56PM +0000, Bruce Richardson
> wrote:
> > > > > >   if (ret < 0 && rte_errno == EAGAIN)
> > > > >
> > > > > i only urge that this be explicit as opposed to a range i.e.
> ret
> > == -
> > > > 1
> > > > > preferred over ret < 0
> > > >
> > > > I don't understand why you think it is important to limit return
> > value
> > > > to -1.
> > > > Why "if (ret == -1)" is better than "if (ret < 0)" ?
> > >
> > > Speaking for myself:
> > >
> > > For clarity. It leaves no doubt that "it failed" is represented by
> > the return value -1, and that the function does not return errno
> values
> > such as
> > > -EINVAL.
> > >
> >
> > But why '< 0' gives you less clarity?
> > Negative value means failure - seems perfectly clear to me.
> 
> 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?



  reply	other threads:[~2021-12-03 10:37 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 [this message]
2021-12-08 17:34                       ` Tyler Retzlaff
2021-12-08 18:40                         ` Morten Brørup
2021-12-09 19:43                           ` Tyler Retzlaff
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=98CBD80474FA8B44BF855DF32C47DC35D86D35@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.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=roretzla@linux.microsoft.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).