lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20140529223906.c79827145882d8a7e270b68a@mindspring.com>
Date:	Thu, 29 May 2014 22:39:06 -0400
From:	Bill Fink <billfink@...dspring.com>
To:	Spike White <spikewhitetx@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: inconsistency of ethtool feature names for get vs. set

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ