[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190208071004.GB7035@unicorn.suse.cz>
Date: Fri, 8 Feb 2019 08:10:04 +0100
From: Michal Kubecek <mkubecek@...e.cz>
To: netdev@...r.kernel.org
Cc: "Nunley, Nicholas D" <nicholas.d.nunley@...el.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"linville@...driver.com" <linville@...driver.com>,
"nhorman@...hat.com" <nhorman@...hat.com>,
"sassmann@...hat.com" <sassmann@...hat.com>
Subject: Re: [PATCH v2 4/6] ethtool: support per-queue sub command
--show-coalesce
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
Powered by blists - more mailing lists