From: Eric Dumazet on
Le mercredi 02 juin 2010 à 15:25 -0700, Jeff Kirsher a écrit :
> From: Alexander Duyck <alexander.h.duyck(a)intel.com>
>
> x86 architectures can handle unaligned accesses in hardware, and it has
> been shown that unaligned DMA accesses can be expensive on Nehalem
> architectures. As such we should overwrite NET_IP_ALIGN and NET_SKB_PAD
> to resolve this issue.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
> ---
>
> arch/x86/include/asm/system.h | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
> index b8fe48e..8acb44e 100644
> --- a/arch/x86/include/asm/system.h
> +++ b/arch/x86/include/asm/system.h
> @@ -457,4 +457,16 @@ static inline void rdtsc_barrier(void)
> alternative(ASM_NOP3, "lfence", X86_FEATURE_LFENCE_RDTSC);
> }
>
> +#ifdef CONFIG_MCORE2
> +/*
> + * We handle most unaligned accesses in hardware. On the other hand
> + * unaligned DMA can be quite expensive on some Nehalem processors.
> + *
> + * Based on this we disable the IP header alignment in network drivers.
> + * We also modify NET_SKB_PAD to be a cacheline in size, thus maintaining
> + * cacheline alignment of buffers.
> + */
> +#define NET_IP_ALIGN 0
> +#define NET_SKB_PAD L1_CACHE_BYTES
> +#endif
> #endif /* _ASM_X86_SYSTEM_H */
>
> --

But... L1_CACHE_BYTES is 64 on MCORE2, so this matches current
NET_SKB_PAD definition...

#ifndef NET_SKB_PAD
#define NET_SKB_PAD 64
#endif



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Duyck, Alexander H on
Eric Dumazet wrote:
> Le mercredi 02 juin 2010 à 15:25 -0700, Jeff Kirsher a écrit :
>> From: Alexander Duyck <alexander.h.duyck(a)intel.com>
>>
>> x86 architectures can handle unaligned accesses in hardware, and it
>> has been shown that unaligned DMA accesses can be expensive on
>> Nehalem architectures. As such we should overwrite NET_IP_ALIGN and
>> NET_SKB_PAD to resolve this issue.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> ---
>>
>> arch/x86/include/asm/system.h | 12 ++++++++++++
>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/system.h
>> b/arch/x86/include/asm/system.h index b8fe48e..8acb44e 100644 ---
>> a/arch/x86/include/asm/system.h +++ b/arch/x86/include/asm/system.h
>> @@ -457,4 +457,16 @@ static inline void rdtsc_barrier(void)
>> alternative(ASM_NOP3, "lfence", X86_FEATURE_LFENCE_RDTSC); }
>>
>> +#ifdef CONFIG_MCORE2
>> +/*
>> + * We handle most unaligned accesses in hardware. On the other hand
>> + * unaligned DMA can be quite expensive on some Nehalem processors.
>> + * + * Based on this we disable the IP header alignment in network
>> drivers. + * We also modify NET_SKB_PAD to be a cacheline in size,
>> thus maintaining + * cacheline alignment of buffers.
>> + */
>> +#define NET_IP_ALIGN 0
>> +#define NET_SKB_PAD L1_CACHE_BYTES
>> +#endif
>> #endif /* _ASM_X86_SYSTEM_H */
>>
>> --
>
> But... L1_CACHE_BYTES is 64 on MCORE2, so this matches current
> NET_SKB_PAD definition...
>
> #ifndef NET_SKB_PAD
> #define NET_SKB_PAD 64
> #endif

I admit the current definition is redundant, but NET_SKB_PAD had been 32 until your recent change of the value, and prior to 2.6.30 the value was 16. If the value were to change again it would silently break the cacheline alignment which is provided by this patch. If we were to define NET_SKB_PAD using L1_CACHE_BYTES in skbuff.h then I might be more inclined to to pull the NET_SKB_PAD change, but right now I would prefer to treat NET_SKB_PAD as a magic number that coincidently is the same size as the L1 cache on MCORE2.

Thanks,

Alex
From: David Miller on
From: "Duyck, Alexander H" <alexander.h.duyck(a)intel.com>
Date: Wed, 2 Jun 2010 16:55:16 -0700

> Eric Dumazet wrote:
>>
>> But... L1_CACHE_BYTES is 64 on MCORE2, so this matches current
>> NET_SKB_PAD definition...
>>
>> #ifndef NET_SKB_PAD
>> #define NET_SKB_PAD 64
>> #endif
>
> I admit the current definition is redundant, but NET_SKB_PAD had
> been 32 until your recent change of the value, and prior to 2.6.30
> the value was 16. If the value were to change again it would
> silently break the cacheline alignment which is provided by this
> patch. If we were to define NET_SKB_PAD using L1_CACHE_BYTES in
> skbuff.h then I might be more inclined to to pull the NET_SKB_PAD
> change, but right now I would prefer to treat NET_SKB_PAD as a magic
> number that coincidently is the same size as the L1 cache on MCORE2.

Eric, why don't we do that? Make NET_SKB_PAD's define L1_CACHE_BYTES.

Reading the comments you added when the default value was changed to
64, this seems to even be your overall intent. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/