* Ethtool question @ 2017-10-11 16:51 Ben Greear 2017-10-11 20:44 ` John W. Linville 0 siblings, 1 reply; 7+ messages in thread From: Ben Greear @ 2017-10-11 16:51 UTC (permalink / raw) To: netdev 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 Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ethtool question 2017-10-11 16:51 Ethtool question Ben Greear @ 2017-10-11 20:44 ` John W. Linville 2017-10-11 20:49 ` David Miller 0 siblings, 1 reply; 7+ messages in thread From: John W. Linville @ 2017-10-11 20:44 UTC (permalink / raw) To: Ben Greear; +Cc: netdev 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? John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ethtool question 2017-10-11 20:44 ` John W. Linville @ 2017-10-11 20:49 ` David Miller 2017-10-12 21:45 ` Ben Greear 0 siblings, 1 reply; 7+ messages in thread From: David Miller @ 2017-10-11 20:49 UTC (permalink / raw) To: linville; +Cc: greearb, netdev 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ethtool question 2017-10-11 20:49 ` David Miller @ 2017-10-12 21:45 ` Ben Greear 2017-10-12 22:00 ` Roopa Prabhu 0 siblings, 1 reply; 7+ messages in thread From: Ben Greear @ 2017-10-12 21:45 UTC (permalink / raw) To: David Miller, linville; +Cc: netdev 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ethtool question 2017-10-12 21:45 ` Ben Greear @ 2017-10-12 22:00 ` Roopa Prabhu 2017-10-16 18:10 ` Ben Greear 0 siblings, 1 reply; 7+ messages in thread From: Roopa Prabhu @ 2017-10-12 22:00 UTC (permalink / raw) To: Ben Greear; +Cc: David Miller, John W. Linville, netdev@vger.kernel.org On Thu, Oct 12, 2017 at 2:45 PM, Ben Greear <greearb@candelatech.com> wrote: > 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. This error is returned by ethtool user-space. It does a get, check and then set if user has requested changes. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ethtool question 2017-10-12 22:00 ` Roopa Prabhu @ 2017-10-16 18:10 ` Ben Greear 2017-10-17 7:49 ` Gal Pressman 0 siblings, 1 reply; 7+ messages in thread From: Ben Greear @ 2017-10-16 18:10 UTC (permalink / raw) To: Roopa Prabhu; +Cc: David Miller, John W. Linville, netdev@vger.kernel.org On 10/12/2017 03:00 PM, Roopa Prabhu wrote: > On Thu, Oct 12, 2017 at 2:45 PM, Ben Greear <greearb@candelatech.com> wrote: >> 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. > > > This error is returned by ethtool user-space. It does a get, check and > then set if user has requested changes. > So, should we fix ethtool to return 0 in this case instead of an error code? I think so. If the driver itself returns an error, then probably return the error code and/or fix the driver as seems appropriate. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ethtool question 2017-10-16 18:10 ` Ben Greear @ 2017-10-17 7:49 ` Gal Pressman 0 siblings, 0 replies; 7+ messages in thread From: Gal Pressman @ 2017-10-17 7:49 UTC (permalink / raw) To: Ben Greear, Roopa Prabhu Cc: David Miller, John W. Linville, netdev@vger.kernel.org On 16-Oct-17 21:10, Ben Greear wrote: > On 10/12/2017 03:00 PM, Roopa Prabhu wrote: >> On Thu, Oct 12, 2017 at 2:45 PM, Ben Greear <greearb@candelatech.com> wrote: >>> 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. >> >> >> This error is returned by ethtool user-space. It does a get, check and >> then set if user has requested changes. >> > > So, should we fix ethtool to return 0 in this case instead of an error code? > > I think so. If the driver itself returns an error, then probably return the > error code and/or fix the driver as seems appropriate. > > Thanks, > Ben > FWIW, seems like the code isn't consistent in this matter. Setting pause/channels/coalescing with the same values will return an error code, but setting EEE will return success. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-10-17 7:49 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2017-10-12 22:00 ` Roopa Prabhu 2017-10-16 18:10 ` Ben Greear 2017-10-17 7:49 ` Gal Pressman
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.