From: Stephen Hemminger <stephen@networkplumber.org>
To: Akhil Goyal <gakhil@marvell.com>
Cc: Kamil Godzwon <kamilx.godzwon@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>, Fan Zhang <fanzhang.oss@gmail.com>
Subject: Re: [EXT] Re: [PATCH v2] lib/cryptodev: fix assertion to remove GCC compilation warning
Date: Tue, 23 May 2023 09:00:33 -0700 [thread overview]
Message-ID: <20230523090033.145f635b@hermes.local> (raw)
In-Reply-To: <CO6PR18MB448402F53FD93D86F66D6EBCD8409@CO6PR18MB4484.namprd18.prod.outlook.com>
On Tue, 23 May 2023 08:12:28 +0000
Akhil Goyal <gakhil@marvell.com> wrote:
> >
> > This could happen if the passed in length to this routine was larger than
> > the amount of data in the mbuf. Should the function check and return an error?
> >
> > Panic should only be reserved for seriously corrupted input (like invalid mbuf).
> >
> > Also, this is a big enough function that it really should not be inlined.
>
> This is a datapath API. RTE_ASSERT is normally not enabled in release build.
> So, this assert is not doing any check for normal scenario.
> We normally avoid these type of error checks in the datapath.
> And while building in debug mode, we need these asserts to give a backtrace also
> To debug the rootcause of the issue.
>
> I would suggest fixing the assert itself instead of adding a check.
> Current patch will affect performance.
>
> Agreed, that the function is big for being an inline function,
> but that is what all the datapath APIs are and
> we keep them inline to improve the performance.
Inline is not a magic go fast switch. Turns out that the compilers and cpu's
already do good job with functions. Using LTO helps too.
next prev parent reply other threads:[~2023-05-23 16:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 18:49 [PATCH] lib/cryptodev: fix assertion to remove GCC compilation warning Kamil Godzwon
2023-05-22 19:04 ` [PATCH v2] " Kamil Godzwon
2023-05-22 21:25 ` Stephen Hemminger
2023-05-23 8:12 ` [EXT] " Akhil Goyal
2023-05-23 16:00 ` Stephen Hemminger [this message]
2023-05-24 7:21 ` Akhil Goyal
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=20230523090033.145f635b@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=fanzhang.oss@gmail.com \
--cc=gakhil@marvell.com \
--cc=kamilx.godzwon@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.