diff options
author | Andy Gospodarek <andy@greyhouse.net> | 2010-06-11 16:47:03 +0400 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2010-06-14 05:20:53 +0400 |
commit | 28c8e4790ca5ef75f54895ca46437f9fbb433ddf (patch) | |
tree | 335150601c08e1eecb819ce638e11430235ba4c1 /net | |
parent | 7837e58ce39bd727e0a163e7d34e479df36f6d29 (diff) | |
download | linux-28c8e4790ca5ef75f54895ca46437f9fbb433ddf.tar.xz |
ixgbe: fix automatic LRO/RSC settings for low latency
This patch added to 2.6.34:
commit f8d1dcaf88bddc7f282722ec1fdddbcb06a72f18
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Tue Apr 27 01:37:20 2010 +0000
ixgbe: enable extremely low latency
introduced a feature where LRO (called RSC on the hardware) was disabled
automatically when setting rx-usecs to 0 via ethtool. Some might not
like the fact that LRO was disabled automatically, but I'm fine with
that. What I don't like is that LRO/RSC is automatically enabled when
rx-usecs is set >0 via ethtool.
This would certainly be a problem if the device was used for forwarding
and it was determined that the low latency wasn't needed after the
device was already forwarding. I played around with saving the state of
LRO in the driver, but it just didn't seem worthwhile and would require
a small change to dev_disable_lro() that I did not like.
This patch simply leaves LRO disabled when setting rx-usecs >0 and
requires that the user enable it again. An extra informational message
will also now appear in the log so users can understand why LRO isn't
being enabled as they expect.
Inconsistency of LRO setting first noticed by Stanislaw Gruszka.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
CC: Stanislaw Gruszka <sgruszka@redhat.com>
CC: stable@kernel.org
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions