Re: inconsistency of ethtool feature names for get vs. set

[Bill Fink <billfink@mindspring.com>]

On Thu, 29 May 2014, Spike White wrote:

> Bill Fink <billfink <at> mindspring.com> writes:
> 
> > 
> > On Thu, 2 Jan 2014, Ben Hutchings wrote:
> > 
> > > On Thu, 2014-01-02 at 15:03 +0000, Ben Hutchings wrote:
> > > > On Thu, 2014-01-02 at 11:47 +0200, Or Gerlitz wrote:
> > > [...]
> > > > > $ ethtool -k eth1  | grep generic-receive-offload
> > > > > generic-receive-offload: on
> > > > > 
> > > > > $ ethtool -K eth1  generic-receive-offload off
> > > > > ethtool: bad command line argument(s)
> > > > > For more information run ethtool -h
> > > > > 
> > > > > --> looking in the sources and realizing I need to use "rx-gro"
> > > > 
> > > > Or 'gro'.  All the old feature names that can be used with the -K 
> option
> > > > are listed in the manual page.  All the new feature names are 
> consistent
> > > > between -k/-K.
> > > 
> > > By 'new feature names' I mean names for features that weren't 
> previously
> > > exposed through ethtool.
> > > 
> > > [...]
> > > > > Basically, this can be resolved by fairly simple patch, but I 
> wasn't 
> > > > > sure if you want it in user space, in the kernel or both...
> > > > 
> > > > How do you intend to resolve this, given the compatibility 
> requirement
> > > > that the old names must still be reported by -k and accepted by -K?
> > > 
> > > Just to be clear, I do see that there's a problem here but the fix may
> > > have to be mostly or entirely in documentation rather than code.
> > 
> > Wouldn't one simple option be to allow the long form like
> > generic-receive-offload for setting in addition to the existing
> > shortcuts rx-gro and gro?  That way a user doing "ethtool -k"
> > could use the name provided to do a set via "ethtool -K" without
> > needing to consult a man page (or "ethtool -h"), while still
> > allowing more knowledgeable users to use the shortcut names.
> > 
> > 					-Bill
> > 
> 
> I love Bill's suggestion. 
> 
> For instance, I have a mandate from my network engineering team to disable 
> all offloads on all Linux VMs.  (don't ask).
> 
> I plagiarized the below code.  But it uses the same keywords that it gets 
> from -k to call -K.  So it fails.
> 
> So I have to continue to play whack-a-mole.  As new offloads arise, 
> decipher the translation (via viewing man pages, etc.)

Someone, I believe Ben Hutchings, had an ethtool patch that
accomplished my suggestion.  Ben just needed someone to test
it.  I unfortunately didn't have time back then to do the
testing myself, nor do I now, but the patch should be in
the archives.

					-Bill