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

Permalink | Reply | 1 comment |
headers
David Miller | 1 Jul 2012 02:38
Favicon

Re: [PATCH v5] sctp: be more restrictive in transport selection on bundled sacks

From: Neil Horman <nhorman <at> tuxdriver.com>
Date: Sat, 30 Jun 2012 08:26:47 -0400

> This is wrong.  Its a counter that increments every time we call sctp_make_sack,
> so that we can create a unique generation identifier for use in tagging which
> transports move ctsn in a given generation.  It saves us from having to iterate
> over a list every time we send a sack. 

Sorry, I missed the counter bump.
Permalink | Reply | 0 comments |
headers
David Miller | 1 Jul 2012 02:39
Favicon

Re: [PATCH v6] sctp: be more restrictive in transport selection on bundled sacks

From: Neil Horman <nhorman <at> tuxdriver.com>
Date: Sat, 30 Jun 2012 09:04:26 -0400

> It was noticed recently that when we send data on a transport, its possible that
> we might bundle a sack that arrived on a different transport.  While this isn't
> a major problem, it does go against the SHOULD requirement in section 6.4 of RFC
> 2960:
> 
>  An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
>    etc.) to the same destination transport address from which it
>    received the DATA or control chunk to which it is replying.  This
>    rule should also be followed if the endpoint is bundling DATA chunks
>    together with the reply chunk.
> 
> This patch seeks to correct that.  It restricts the bundling of sack operations
> to only those transports which have moved the ctsn of the association forward
> since the last sack.  By doing this we guarantee that we only bundle outbound
> saks on a transport that has received a chunk since the last sack.  This brings
> us into stricter compliance with the RFC.
> 
> Vlad had initially suggested that we strictly allow only sack bundling on the
> transport that last moved the ctsn forward.  While this makes sense, I was
> concerned that doing so prevented us from bundling in the case where we had
> received chunks that moved the ctsn on multiple transports.  In those cases, the
> RFC allows us to select any of the transports having received chunks to bundle
> the sack on.  so I've modified the approach to allow for that, by adding a state
> variable to each transport that tracks weather it has moved the ctsn since the
> last sack.  This I think keeps our behavior (and performance), close enough to
> our current profile that I think we can do this without a sysctl knob to
> enable/disable it.
(Continue reading)

Permalink | Reply | 9 comments |
headers
David Miller | 1 Jul 2012 02:41
Favicon

Re: [net] igbvf: fix divide by zero

From: Jeff Kirsher <jeffrey.t.kirsher <at> intel.com>
Date: Sat, 30 Jun 2012 03:23:19 -0700

> From: Mitch A Williams <mitch.a.williams <at> intel.com>
> 
> Using ethtool -C ethX rx-usecs 0 crashes with a divide by zero.
> Refactor this function to fix this issue and make it more clear
> what the intent of each conditional is. Add comment regarding
> using a setting of zero.
> 
> CC: stable <stable <at> vger.kernel.org> [3.3+]
> CC: David Ahern <daahern <at> cisco.com>
> Signed-off-by: Mitch Williams <mitch.a.williams <at> intel.com>
> Tested-by: Aaron Brown <aaron.f.brown <at> intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher <at> intel.com>

Applied, thanks.
Permalink | Reply | 0 comments |
headers
Vlad Yasevich | 1 Jul 2012 05:17
Picon

Re: [PATCH v6] sctp: be more restrictive in transport selection on bundled sacks

David Miller <davem <at> davemloft.net> wrote:

>From: Neil Horman <nhorman <at> tuxdriver.com>
>Date: Sat, 30 Jun 2012 09:04:26 -0400
>
>> It was noticed recently that when we send data on a transport, its
>possible that
>> we might bundle a sack that arrived on a different transport.  While
>this isn't
>> a major problem, it does go against the SHOULDAcm requirement in section
>6.4 of RFC
>> 2960:
>> 
>>  An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
>>    etc.) to the same destination transport address from which it
>>    received the DATA or control chunk to which it is replying.  This
>>    rule should also be followed if the endpoint is bundling DATA
>chunks
>>    together with the reply chunk.
>> 
>> This patch seeks to correct that.  It restricts the bundling of sack
>operations
>> to only those transports which have moved the ctsn of the association
>forward
>> since the last sack.  By doing this we guarantee that we only bundle
>outbound
>> saks on a transport that has received a chunk since the last sack. 
>This brings
>> us into stricter compliance with the RFC.
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hannes Frederic Sowa | 1 Jul 2012 05:57
Picon

Re: [PATCH V3 2/2] bonding support for IPv6 transmit hashing

On Sat, Jun 30, 2012 at 9:38 PM, John <linux <at> 8192.net> wrote:
> On 6/30/2012 4:59 AM, Hannes Frederic Sowa wrote:
>> On Sat, Jun 30, 2012 at 8:17 AM, John <linux <at> 8192.net> wrote:
>>>
>>> diff --git a/Documentation/networking/bonding.txt
>>> b/Documentation/networking/bonding.txt
>>> index bfea8a3..5db14fe 100644
>>> --- a/Documentation/networking/bonding.txt
>>> +++ b/Documentation/networking/bonding.txt
>>>  <at>  <at>  -752,12 +752,22  <at>  <at>  xmit_hash_policy
>>>                  protocol information to generate the hash.
>>>
>>>                  Uses XOR of hardware MAC addresses and IP addresses to
>>> -               generate the hash.  The formula is
>>> +               generate the hash.  The IPv4 formula is
>>>
>>>                  (((source IP XOR dest IP) AND 0xffff) XOR
>>>                          ( source MAC XOR destination MAC ))
>>>                                  modulo slave count
>>>
>>> +               The IPv6 forumla is
>>> +
>>> +               iphash =
>>> +                       (source ip quad 2 XOR dest IP quad 2) XOR
>>> +                       (source ip quad 3 XOR dest IP quad 3) XOR
>>> +                       (source ip quad 4 XOR dest IP quad 4)
>>> +
>>> +               ((iphash >> 16) XOR (iphash >> 8) XOR iphash)
>>> +                       modulo slave count
>>> +
(Continue reading)

Permalink | Reply | 0 comments |
headers
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)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Jul 2012 07:39
Favicon

Re: [PATCH] ipv4: Elide fib_validate_source() completely when possible.

From: Julian Anastasov <ja <at> ssi.bg>
Date: Sat, 30 Jun 2012 13:45:52 +0300 (EEST)

> 	If we really want a change in behavior we should
> at least update the accept_local info in
> Documentation/networking/ip-sysctl.txt ?

Thanks for pointing this out, that's what I will do.

====================
ipv4: Clarify in docs that accept_local requires rp_filter.

Signed-off-by: David S. Miller <davem <at> davemloft.net>
---
 Documentation/networking/ip-sysctl.txt |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 99d0e05..47b6c79 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
 <at>  <at>  -857,9 +857,14  <at>  <at>  accept_source_route - BOOLEAN
 		FALSE (host)

 accept_local - BOOLEAN
-	Accept packets with local source addresses. In combination with
-	suitable routing, this can be used to direct packets between two
-	local interfaces over the wire and have them accepted properly.
+	Accept packets with local source addresses. In combination
+	with suitable routing, this can be used to direct packets
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Jul 2012 07:44
Favicon

Re: [PATCH v6] sctp: be more restrictive in transport selection on bundled sacks

From: Vlad Yasevich <vyasevich <at> gmail.com>
Date: Sat, 30 Jun 2012 23:17:52 -0400

> David Miller <davem <at> davemloft.net> wrote:
> 
>>Once this has Vlad's ACK I'll apply it.
> 
> Acked-by: Vlad Yasevich <vyasevich <at> gmail.com>

Applied, thanks everyone.
Permalink | Reply | 0 comments |
headers
Jeff Kirsher | 1 Jul 2012 08:02
Picon
Favicon

[net] 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.

CC: stable <stable <at> vger.kernel.org> [3.4]
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>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane