From: Simon Horman <simon.horman@netronome.com>
To: Scott Feldman <sfeldma@gmail.com>
Cc: David Laight <David.Laight@aculab.com>,
Jiri Pirko <jiri@resnulli.us>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH/RFC net-next] rocker: remove rocker parameter from functions that have rocker_port parameter
Date: Mon, 1 Jun 2015 13:25:25 +0900 [thread overview]
Message-ID: <20150601042522.GA6026@vergenet.net> (raw)
In-Reply-To: <CAE4R7bC7qt9LhDqvpb-ZvWB6te=nf4DgXrC0T4NT7DX2yrCgrw@mail.gmail.com>
On Thu, May 28, 2015 at 08:53:20AM -0700, Scott Feldman wrote:
> On Thu, May 28, 2015 at 2:18 AM, David Laight <David.Laight@aculab.com> wrote:
> > From: Simon Horman
> >> Sent: 28 May 2015 04:23
> >> The rocker (switch) of a rocker_port may be trivially obtained from
> >> the latter it seems cleaner not to pass the former to a function when
> >> the latter is being passed anyway.
> >
> > If the arguments are passed in registers (they almost certainly are)
> > or the function is inlined (possible since they are static) and
> > the calling code already has both values in registers then
> > passing both values saves a memory read inside the called code.
> >
> > So on 'hot paths' it probably makes sense to pass both values.
>
> Agreed, and Simon's patch is 99% cold path, so I'd rather trade
> clarity in the code than saving a nanosec in a driver cold path.
>
> Simon, would you respin, remove rocker_port_rx_proc() changes, remove
> RFC, and add my ack? rocker_port_rx_proc() was the only hot path case
> I found.
Sure, that seems reasonable to me. I have done so.
prev parent reply other threads:[~2015-06-01 4:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-28 3:23 [PATCH/RFC net-next] rocker: remove rocker parameter from functions that have rocker_port parameter Simon Horman
2015-05-28 5:11 ` Scott Feldman
2015-05-28 6:15 ` Jiri Pirko
2015-05-28 8:30 ` Simon Horman
2015-05-28 9:18 ` David Laight
2015-05-28 15:53 ` Scott Feldman
2015-06-01 4:25 ` Simon Horman [this message]
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=20150601042522.GA6026@vergenet.net \
--to=simon.horman@netronome.com \
--cc=David.Laight@aculab.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@gmail.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.