From: Ben Greear <greearb@candelatech•com>
To: David Miller <davem@davemloft•net>, linville@tuxdriver•com
Cc: netdev@vger•kernel.org
Subject: Re: Ethtool question
Date: Thu, 12 Oct 2017 14:45:25 -0700 [thread overview]
Message-ID: <59DFE275.3050805@candelatech.com> (raw)
In-Reply-To: <20171011.134919.321292333200236097.davem@davemloft.net>
On 10/11/2017 01:49 PM, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver•com>
> Date: Wed, 11 Oct 2017 16:44:07 -0400
>
>> On Wed, Oct 11, 2017 at 09:51:56AM -0700, Ben Greear wrote:
>>> I noticed today that setting some ethtool settings to the same value
>>> returns an error code. I would think this should silently return
>>> success instead? Makes it easier to call it from scripts this way:
>>>
>>> [root@lf0313-6477 lanforge]# ethtool -L eth3 combined 1
>>> combined unmodified, ignoring
>>> no channel parameters changed, aborting
>>> current values: tx 0 rx 0 other 1 combined 1
>>> [root@lf0313-6477 lanforge]# echo $?
>>> 1
>>
>> I just had this discussion a couple of months ago with someone. My
>> initial feeling was like you, a no-op is not a failure. But someone
>> convinced me otherwise...I will now endeavour to remember who that
>> was and how they convinced me...
>>
>> Anyone else have input here?
>
> I guess this usually happens when drivers don't support changing the
> settings at all. So they just make their ethtool operation for the
> 'set' always return an error.
>
> We could have a generic ethtool helper that does "get" and then if the
> "set" request is identical just return zero.
>
> But from another perspective, the error returned from the "set" in this
> situation also indicates to the user that the driver does not support
> the "set" operation which has value and meaning in and of itself. And
> we'd lose that with the given suggestion.
In my case, the driver (igb) does support the set, my program just made the same
ethtool call several times and it fails after the initial change (that actually
changes something), as best as I can figure.
Thanks,
Ben
--
Ben Greear <greearb@candelatech•com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2017-10-12 21:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 16:51 Ethtool question Ben Greear
2017-10-11 20:44 ` John W. Linville
2017-10-11 20:49 ` David Miller
2017-10-12 21:45 ` Ben Greear [this message]
2017-10-12 22:00 ` Roopa Prabhu
2017-10-16 18:10 ` Ben Greear
2017-10-17 7:49 ` Gal Pressman
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=59DFE275.3050805@candelatech.com \
--to=greearb@candelatech$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=linville@tuxdriver$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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