From: Michal Kubecek <mkubecek@suse.cz>
To: netdev@vger.kernel.org
Cc: "Nunley, Nicholas D" <nicholas.d.nunley@intel.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"linville@tuxdriver.com" <linville@tuxdriver.com>,
"nhorman@redhat.com" <nhorman@redhat.com>,
"sassmann@redhat.com" <sassmann@redhat.com>
Subject: Re: [PATCH v2 4/6] ethtool: support per-queue sub command --show-coalesce
Date: Fri, 8 Feb 2019 08:10:04 +0100 [thread overview]
Message-ID: <20190208071004.GB7035@unicorn.suse.cz> (raw)
In-Reply-To: <146CDE3B8C383A4B88452B498CB0FBBBFD9C3FE9@ORSMSX157.amr.corp.intel.com>
On Thu, Feb 07, 2019 at 11:53:40PM +0000, Nunley, Nicholas D wrote:
> > > @@ -5390,7 +5438,19 @@ static int do_perqueue(struct cmd_context *ctx)
> > > if (i < 0)
> > > exit_bad_args();
> > >
> > > - /* no sub_command support yet */
> > > + if (strstr(args[i].opts, "--show-coalesce") != NULL) {
> >
> > Comparing args[i].func to do_gcoalesce might be easier.
>
> This is the one comment where I think it's better to leave the code as it is.
> To me is seems more confusing to match on a function pointer that we're never
> going to call. Unless there are more objections I'd rather keep it the way it
> is.
No problem. This is not a code where performance is crucial. In theory,
you could get into trouble if someone introduces another command
(allowing per queue settings) with name like "--show-coalesce-foo" but
that's not very likely, IMHO.
Michal Kubecek
next prev parent reply other threads:[~2019-02-08 7:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-06 0:01 [PATCH v2 1/6] ethtool: move option parsing related code into function Jeff Kirsher
2019-02-06 0:01 ` [PATCH v2 2/6] ethtool: move cmdline_coalesce out of do_scoalesce Jeff Kirsher
2019-02-06 0:01 ` [PATCH v2 3/6] ethtool: introduce new ioctl for per-queue settings Jeff Kirsher
2019-02-06 9:18 ` Michal Kubecek
2019-02-07 23:37 ` Nunley, Nicholas D
2019-02-08 7:02 ` Michal Kubecek
2019-02-08 13:56 ` Willem de Bruijn
2019-02-06 10:32 ` Michal Kubecek
2019-02-07 23:41 ` Nunley, Nicholas D
2019-02-06 12:43 ` Michal Kubecek
2019-02-07 23:43 ` Nunley, Nicholas D
2019-02-06 0:01 ` [PATCH v2 4/6] ethtool: support per-queue sub command --show-coalesce Jeff Kirsher
2019-02-06 13:22 ` Michal Kubecek
2019-02-07 23:53 ` Nunley, Nicholas D
2019-02-08 7:10 ` Michal Kubecek [this message]
2019-02-06 0:01 ` [PATCH v2 5/6] ethtool: support per-queue sub command --coalesce Jeff Kirsher
2019-02-06 0:01 ` [PATCH v2 6/6] ethtool: fix up dump_coalesce output to match actual option names Jeff Kirsher
2019-02-06 9:56 ` [PATCH v2 1/6] ethtool: move option parsing related code into function Michal Kubecek
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=20190208071004.GB7035@unicorn.suse.cz \
--to=mkubecek@suse.cz \
--cc=jeffrey.t.kirsher@intel.com \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=nicholas.d.nunley@intel.com \
--cc=sassmann@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox