inconsistency of ethtool feature names for get vs. set

inconsistency of ethtool feature names for get vs. set

[Or Gerlitz]

Hi Ben,

I noticed some inconsistency of feature names with the ethtool 
getting/setting of features mechanics -- the name of the feature you 
need to set (through -K) isn't what displayed by the get (-k) directive, 
here's an example:

$ 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"

$ ethtool -K eth1  rx-gro on

$ethtool -k eth1  | grep generic-receive-offload
generic-receive-offload: on

same problem for rx checksum which is displayed as "rx-checksumming" by 
the get (-k)
but need to be "rx-checksum" for the set (-K) directive.

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...

Or.

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

[Rami Rosen]

Hi,
3 short comments:

1) This is true also to setting GSO:
ethtool -k enp0s8  | grep generic-segmentation-offload
generic-segmentation-offload: on

ethtool -K enp0s8  generic-segmentation-offload off
ethtool: bad command line argument(s)

and
ethtool -K enp0s8  gso off
works.

and also to setting scatter-gather:
ethtool -k enp0s8  | grep scatter-gather
scatter-gather: off

ethtool -K enp0s8  scatter-gather on
ethtool: bad command line argument(s)

And
ethtool -K enp0s8  sg on
works.

2)
you said:
> ethtool -K eth1  rx-gro on

You can also use:
ethtool -K eth1  gro on


3)
>same problem for rx checksum which is displayed as "rx-checksumming" >by the get (-k)
>but need to be "rx-checksum" for the set (-K) directive.
You can also use:
ethtool -K eth1  rx on
or
ethtool -K eth1  rx off

The same for tx-checksum:
ethtool -K eth1  tx on
or
ethtool -K eth1  tx off

Regards,
Rami Rosen
http://ramirose.wix.com/ramirosen

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

[Ben Hutchings]

On Thu, 2014-01-02 at 11:47 +0200, Or Gerlitz wrote:
> Hi Ben,
> 
> I noticed some inconsistency of feature names with the ethtool 
> getting/setting of features mechanics -- the name of the feature you 
> need to set (through -K) isn't what displayed by the get (-k) directive, 
> here's an example:

All the feature names used to be in ethtool and they were not consistent
between -k/-K nor with the names that are now generated by the kernel.

> $ 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.

> $ ethtool -K eth1  rx-gro on
> 
> $ethtool -k eth1  | grep generic-receive-offload
> generic-receive-offload: on
> 
> same problem for rx checksum which is displayed as "rx-checksumming" by 
> the get (-k)
> but need to be "rx-checksum" for the set (-K) directive.
> 
> 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?

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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

[Ben Hutchings]

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.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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

[Or Gerlitz]

On Thu, Jan 2, 2014 at 8:41 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:

> 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.

Ben, I am fine with at least starting with documenting this and see
where it takes us, can you pick it up?

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

[Ben Hutchings]

On Thu, 2014-01-02 at 22:12 +0200, Or Gerlitz wrote:
> On Thu, Jan 2, 2014 at 8:41 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> 
> > 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.
> 
> Ben, I am fine with at least starting with documenting this and see
> where it takes us, can you pick it up?

I might do but don't assume I will.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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

[Bill Fink]

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

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

[Spike White]

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.)

#==================================================
# TCP Offloading
# Guidance from network engineering to disable all offloads on all NICs:
# rx tx sg tso ufo gso gro lro rxvlan txvlan rxhash
function fix_offload () {

NICS=$(ifconfig | awk '/^p[0-9][^:]/ || /^eth[0-9][^:]/ || /^em[0-9][^:]/ 
{print $1}')

MODEL=$(dmidecode | grep -i product | head -1 | cut -f2 -d':' | cut -c 2-)

if [[ $MODEL = VMware* ]] && [[ $OS = "OEL6" ]]
then
   # New offloads in OEL6 that ethtool cannot disable on VM's: rxvlan, 
txvlan, & rxhash
   ETHTOOL_PARSE="egrep -v -e 'vlan' -e 'hashing'"
elif [[ -n "$UEK" ]]
then
   # UEK has a bunch of features that we don't care about, so specify what 
we want
   ETHTOOL_PARSE="egrep -e 'checksumming' -e 'scatter' -e 'offload' -
e 'hashing'"
else
   # Grab everything
   ETHTOOL_PARSE="grep ':'"
fi

for i in $NICS
do
   OFFLOADS_ON=$(ethtool -k $i 2> /dev/null | eval $ETHTOOL_PARSE | 
grep ': on' | awk -F: '{print $1 off}')
   if [[ -n "$OFFLOADS_ON" ]]
   then
      echo "NIC $i offloads on"
      ethtool -K $i $OFFLOADS_ON
   else
      echo "PASS: NIC $i offloads off"
   fi
done

}

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

[Bill Fink]

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