netdev - Re: Translation table available between 'ethtool -k' and 'ethtool -K' ? For Linux?

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+mtBx9SJ5mhLBMk8E0gGceweMyzJ2icBfjGJc0rjOTDVQZi1Q@mail.gmail.com>
Date:	Thu, 20 Nov 2014 17:07:44 -0800
From:	Tom Herbert <therbert@...gle.com>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	Spike_White@...l.com, Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: Translation table available between 'ethtool -k' and 'ethtool -K'
 ? For Linux?

On Thu, Nov 20, 2014 at 3:32 PM, Ben Hutchings <ben@...adent.org.uk> wrote:
> On Thu, 2014-11-20 at 15:10 -0600, Spike_White@...l.com wrote:
>> Ethtool developers,
>>
>>
>>
>> Is there a translation table available between the offload names that
>> ethtool –k reports and the offload names that ethool –K accepts?
>>
>>
>>
>> Our network engineering team has to standard to disable all NIC
>> offloads.  I don’t disagree;  several have often bitten us in the
>> past.  LRO on vmxnet3 vNICs, TSO on old NICs and (just now) LRO on
>> ixgbe/Intel NIC.
>
> So instead of properly validating drivers, you just assume they all have
> the same bug as something you saw in the past?
>
> You may think you're being conservative, but by using non-default
> settings you're actually taking more of a risk.
>
Ben I'm not sure I see this. If we turn off HW offloads and rely on
the software offloads where is the increased risk? This may result in
performance degradation for sure, but I really hope at this point that
the software offload mechanisms in the stack are as least as robust as
any HW mechanism.

>> And we have CPU for days, never CPU-limited on our servers.
>
> Lucky you.  It's a shame about the power going to waste.
>
>> If ethtool –K accepted the offload format that –k reports, then
>> disabling all offloads would be trivial:
> [...]
>> Is there a translation table somewhere that translates from the ‘-k’
>> output offload names to the ‘-K’ style offload names?
> [...]
>
> Yes, it's the off_flag_def array.
>
> For any newly defined features, ethtool will simply use the name
> supplied by the kernel for both -k output and -K argument parsing.
>
> Ben.
>
> --
> Ben Hutchings
> Man invented language to satisfy his deep need to complain. - Lily Tomlin
--
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