From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: "Geneviève Bastien" <gbastien@versatic.net>,
"David S. Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>, "Ingo Molnar" <mingo@redhat.com>
Subject: Re: [PATCH v2] net: Add trace events for all receive exit points
Date: Mon, 12 Nov 2018 20:47:03 -0500 [thread overview]
Message-ID: <20181112204703.0bd2b627@vmware.local.home> (raw)
In-Reply-To: <1354786248.4048.1542055613213.JavaMail.zimbra@efficios.com>
On Mon, 12 Nov 2018 15:46:53 -0500 (EST)
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> I also notice that in two cases, a "gro_result_t" is implicitly cast
> to "int". I usually frown upon this kind of stuff, because it's asking
> for trouble if gro_result_t typedef to something else than "int" in the
> future.
>
> I would recommend going for two templates, one which takes a "int"
> ret parameter, and the other a "gro_result_t" ret parameter.
>
> Or am I being too cautious ?
That's more of a question for the netdev maintainers. If they think
casting gro_result_t to int is fine, then I'm fine. If it breaks in the
future, they need to deal with it, I don't ;-)
The downside of two templates, is that the templates are the bloated
part of the trace event (DEFINE_EVENT()s are light weight). They can
add a couple of K to the memory foot print.
-- Steve
next prev parent reply other threads:[~2018-11-13 11:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-12 19:44 [PATCH v2] net: Add trace events for all receive exit points Geneviève Bastien
2018-11-12 20:09 ` Mathieu Desnoyers
2018-11-12 20:20 ` Mathieu Desnoyers
2018-11-12 20:37 ` Mathieu Desnoyers
2018-11-12 20:40 ` Steven Rostedt
2018-11-12 20:46 ` Mathieu Desnoyers
2018-11-12 20:56 ` Mathieu Desnoyers
2018-11-13 1:47 ` Steven Rostedt [this message]
2018-11-12 20:32 ` Steven Rostedt
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=20181112204703.0bd2b627@vmware.local.home \
--to=rostedt@goodmis.org \
--cc=davem@davemloft.net \
--cc=gbastien@versatic.net \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
/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).