* Re: Translation table available between 'ethtool -k' and 'ethtool -K' ? For Linux? [not found] <BABF60987D48764FA4071AC73CB9C56162EBFBD0AC@AUSX7MCPC101.AMER.DELL.COM> @ 2014-11-20 23:32 ` Ben Hutchings 2014-11-20 23:35 ` David Miller 2014-11-21 1:07 ` Tom Herbert 0 siblings, 2 replies; 6+ messages in thread From: Ben Hutchings @ 2014-11-20 23:32 UTC (permalink / raw) To: Spike_White; +Cc: netdev [-- Attachment #1: Type: text/plain, Size: 1399 bytes --] On Thu, 2014-11-20 at 15:10 -0600, Spike_White@Dell.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. > 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 811 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Translation table available between 'ethtool -k' and 'ethtool -K' ? For Linux? 2014-11-20 23:32 ` Translation table available between 'ethtool -k' and 'ethtool -K' ? For Linux? Ben Hutchings @ 2014-11-20 23:35 ` David Miller 2014-11-21 1:07 ` Tom Herbert 1 sibling, 0 replies; 6+ messages in thread From: David Miller @ 2014-11-20 23:35 UTC (permalink / raw) To: ben; +Cc: Spike_White, netdev From: Ben Hutchings <ben@decadent.org.uk> Date: Thu, 20 Nov 2014 23:32:34 +0000 > 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. +1 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Translation table available between 'ethtool -k' and 'ethtool -K' ? For Linux? 2014-11-20 23:32 ` Translation table available between 'ethtool -k' and 'ethtool -K' ? For Linux? Ben Hutchings 2014-11-20 23:35 ` David Miller @ 2014-11-21 1:07 ` Tom Herbert 2014-11-21 4:05 ` David Miller 1 sibling, 1 reply; 6+ messages in thread From: Tom Herbert @ 2014-11-21 1:07 UTC (permalink / raw) To: Ben Hutchings; +Cc: Spike_White, Linux Netdev List On Thu, Nov 20, 2014 at 3:32 PM, Ben Hutchings <ben@decadent.org.uk> wrote: > On Thu, 2014-11-20 at 15:10 -0600, Spike_White@Dell.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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Translation table available between 'ethtool -k' and 'ethtool -K' ? For Linux? 2014-11-21 1:07 ` Tom Herbert @ 2014-11-21 4:05 ` David Miller 2014-11-21 4:36 ` Tom Herbert 0 siblings, 1 reply; 6+ messages in thread From: David Miller @ 2014-11-21 4:05 UTC (permalink / raw) To: therbert; +Cc: ben, Spike_White, netdev From: Tom Herbert <therbert@google.com> Date: Thu, 20 Nov 2014 17:07:44 -0800 > 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. It means you're testing a configuration different from %99 of users (who are not changing the defaults). You are by definition testing code paths with less overall global testing coverage. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Translation table available between 'ethtool -k' and 'ethtool -K' ? For Linux? 2014-11-21 4:05 ` David Miller @ 2014-11-21 4:36 ` Tom Herbert [not found] ` <BABF60987D48764FA4071AC73CB9C56162EBFBD4AA@AUSX7MCPC101.AMER.DELL.COM> 0 siblings, 1 reply; 6+ messages in thread From: Tom Herbert @ 2014-11-21 4:36 UTC (permalink / raw) To: David Miller; +Cc: Ben Hutchings, Spike_White, Linux Netdev List On Thu, Nov 20, 2014 at 8:05 PM, David Miller <davem@davemloft.net> wrote: > From: Tom Herbert <therbert@google.com> > Date: Thu, 20 Nov 2014 17:07:44 -0800 > >> 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. > > It means you're testing a configuration different from %99 of users > (who are not changing the defaults). You are by definition testing > code paths with less overall global testing coverage. Remarkably, this is the second time this week I've heard of a user unilaterally turning off LRO/TSO in their network because of perceived issues. I wonder if this is happening more often then we might hope... ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <BABF60987D48764FA4071AC73CB9C56162EBFBD4AA@AUSX7MCPC101.AMER.DELL.COM>]
* Re: Translation table available between 'ethtool -k' and 'ethtool -K' ? For Linux? [not found] ` <BABF60987D48764FA4071AC73CB9C56162EBFBD4AA@AUSX7MCPC101.AMER.DELL.COM> @ 2014-11-22 5:03 ` David Miller 0 siblings, 0 replies; 6+ messages in thread From: David Miller @ 2014-11-22 5:03 UTC (permalink / raw) To: Spike_White; +Cc: therbert, ben, netdev Please don't top-post, thank you. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-11-22 5:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <BABF60987D48764FA4071AC73CB9C56162EBFBD0AC@AUSX7MCPC101.AMER.DELL.COM>
2014-11-20 23:32 ` Translation table available between 'ethtool -k' and 'ethtool -K' ? For Linux? Ben Hutchings
2014-11-20 23:35 ` David Miller
2014-11-21 1:07 ` Tom Herbert
2014-11-21 4:05 ` David Miller
2014-11-21 4:36 ` Tom Herbert
[not found] ` <BABF60987D48764FA4071AC73CB9C56162EBFBD4AA@AUSX7MCPC101.AMER.DELL.COM>
2014-11-22 5:03 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).