Jeff Kirsher | 30 Jun 2012 12:35
Picon
Favicon

[net-next] e1000e: remove use of IP payload checksum

From: Bruce Allan <bruce.w.allan <at> intel.com>

Currently only used when packet split mode is enabled with jumbo frames,
IP payload checksum (for fragmented UDP packets) is mutually exclusive with
receive hashing offload since the hardware uses the same space in the
receive descriptor for the hardware-provided packet checksum and the RSS
hash, respectively.  Users currently must disable jumbos when receive
hashing offload is enabled, or vice versa, because of this incompatibility.
Since testing has shown that IP payload checksum does not provide any real
benefit, just remove it so that there is no longer a choice between jumbos
or receive hashing offload but not both as done in other Intel GbE drivers
(e.g. e1000, igb).

Also, add a missing check for IP checksum error reported by the hardware;
let the stack verify the checksum when this happens.

Signed-off-by: Bruce Allan <bruce.w.allan <at> intel.com>
Tested-by: Aaron Brown <aaron.f.brown <at> intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher <at> intel.com>
---
 drivers/net/ethernet/intel/e1000e/defines.h |    1 +
 drivers/net/ethernet/intel/e1000e/netdev.c  |   75 +++++----------------------
 2 files changed, 15 insertions(+), 61 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/defines.h b/drivers/net/ethernet/intel/e1000e/defines.h
index 351a409..76edbc1 100644
--- a/drivers/net/ethernet/intel/e1000e/defines.h
+++ b/drivers/net/ethernet/intel/e1000e/defines.h
 <at>  <at>  -103,6 +103,7  <at>  <at> 
 #define E1000_RXD_ERR_SEQ       0x04    /* Sequence Error */
(Continue reading)

Ben Hutchings | 30 Jun 2012 23:36
Picon

Re: [net-next] e1000e: remove use of IP payload checksum

On Sat, 2012-06-30 at 03:35 -0700, Jeff Kirsher wrote:
> From: Bruce Allan <bruce.w.allan <at> intel.com>
> 
> Currently only used when packet split mode is enabled with jumbo frames,
> IP payload checksum (for fragmented UDP packets) is mutually exclusive with
> receive hashing offload since the hardware uses the same space in the
> receive descriptor for the hardware-provided packet checksum and the RSS
> hash, respectively.  Users currently must disable jumbos when receive
> hashing offload is enabled, or vice versa, because of this incompatibility.
> Since testing has shown that IP payload checksum does not provide any real
> benefit, just remove it so that there is no longer a choice between jumbos
> or receive hashing offload but not both as done in other Intel GbE drivers
> (e.g. e1000, igb).
> 
> Also, add a missing check for IP checksum error reported by the hardware;
> let the stack verify the checksum when this happens.
[...]

The change to enable RX hashing in 3.4, with this odd restriction seems
to have broken most existing systems using jumbo MTU on e1000e.  None of
the distro scripts or network management daemons will automatically
change offload configuration before MTU; how could they know?

Therefore this needs to be fixed in 3.5 and 3.4.y, not net-next.

Ben.

--

-- 
Ben Hutchings
Lowery's Law:
(Continue reading)

David Miller | 1 Jul 2012 02:37
Favicon

Re: [net-next] e1000e: remove use of IP payload checksum

From: Ben Hutchings <ben <at> decadent.org.uk>
Date: Sat, 30 Jun 2012 22:36:36 +0100

> On Sat, 2012-06-30 at 03:35 -0700, Jeff Kirsher wrote:
>> From: Bruce Allan <bruce.w.allan <at> intel.com>
>> 
>> Currently only used when packet split mode is enabled with jumbo frames,
>> IP payload checksum (for fragmented UDP packets) is mutually exclusive with
>> receive hashing offload since the hardware uses the same space in the
>> receive descriptor for the hardware-provided packet checksum and the RSS
>> hash, respectively.  Users currently must disable jumbos when receive
>> hashing offload is enabled, or vice versa, because of this incompatibility.
>> Since testing has shown that IP payload checksum does not provide any real
>> benefit, just remove it so that there is no longer a choice between jumbos
>> or receive hashing offload but not both as done in other Intel GbE drivers
>> (e.g. e1000, igb).
>> 
>> Also, add a missing check for IP checksum error reported by the hardware;
>> let the stack verify the checksum when this happens.
> [...]
> 
> The change to enable RX hashing in 3.4, with this odd restriction seems
> to have broken most existing systems using jumbo MTU on e1000e.  None of
> the distro scripts or network management daemons will automatically
> change offload configuration before MTU; how could they know?
> 
> Therefore this needs to be fixed in 3.5 and 3.4.y, not net-next.

Agreed.
(Continue reading)

Jeff Kirsher | 1 Jul 2012 07:32
Picon
Favicon

Re: [net-next] e1000e: remove use of IP payload checksum

On Sat, 2012-06-30 at 17:37 -0700, David Miller wrote:
> From: Ben Hutchings <ben <at> decadent.org.uk>
> Date: Sat, 30 Jun 2012 22:36:36 +0100
> 
> > On Sat, 2012-06-30 at 03:35 -0700, Jeff Kirsher wrote:
> >> From: Bruce Allan <bruce.w.allan <at> intel.com>
> >> 
> >> Currently only used when packet split mode is enabled with jumbo frames,
> >> IP payload checksum (for fragmented UDP packets) is mutually exclusive with
> >> receive hashing offload since the hardware uses the same space in the
> >> receive descriptor for the hardware-provided packet checksum and the RSS
> >> hash, respectively.  Users currently must disable jumbos when receive
> >> hashing offload is enabled, or vice versa, because of this incompatibility.
> >> Since testing has shown that IP payload checksum does not provide any real
> >> benefit, just remove it so that there is no longer a choice between jumbos
> >> or receive hashing offload but not both as done in other Intel GbE drivers
> >> (e.g. e1000, igb).
> >> 
> >> Also, add a missing check for IP checksum error reported by the hardware;
> >> let the stack verify the checksum when this happens.
> > [...]
> > 
> > The change to enable RX hashing in 3.4, with this odd restriction seems
> > to have broken most existing systems using jumbo MTU on e1000e.  None of
> > the distro scripts or network management daemons will automatically
> > change offload configuration before MTU; how could they know?
> > 
> > Therefore this needs to be fixed in 3.5 and 3.4.y, not net-next.
> 
> Agreed.
(Continue reading)


Gmane