In many cases, especially in networking, it can be beneficial to
know at compile time whether the architecture can do unaligned
accesses. This patch introduces a new Kconfig symbol
ARCH_CAN_UNALIGNED_ACCESS
for that purpose and adds it to the powerpc and x86 architectures.
Also add some documentation about alignment and networking, and
especially one intended use of this symbol.
Signed-off-by: Johannes Berg <[email protected]>
---
Users will be added later, especially wireless networking can benefit.
Documentation/unaligned-memory-access.txt | 32 +++++++++++++++++++++++++++---
arch/powerpc/Kconfig | 3 ++
arch/x86/Kconfig | 3 ++
3 files changed, 35 insertions(+), 3 deletions(-)
--- everything.orig/Documentation/unaligned-memory-access.txt 2008-03-20 15:19:06.000000000 +0100
+++ everything/Documentation/unaligned-memory-access.txt 2008-03-20 15:29:13.000000000 +0100
@@ -218,9 +218,35 @@ If use of such macros is not convenient,
where the source or destination (or both) are of type u8* or unsigned char*.
Due to the byte-wise nature of this operation, unaligned accesses are avoided.
+
+Alignment vs. Networking
+========================
+
+On architectures that require aligned loads, networking requires that the IP
+header is aligned on a four-byte boundary to optimise the IP stack. For
+regular ethernet hardware, the constant NET_IP_ALIGN is used, on most
+architectures this constant has the value 2 because the normal ethernet
+header is 14 bytes long, so in order to get proper alignment one needs to
+DMA to an address that is can be expressed as 4*n + 2. One notable exception
+here is powerpc which defines NET_IP_ALIGN to 0 because DMA to unaligned
+addresses can be very expensive and dwarf the cost of unaligned loads.
+
+For some ethernet hardware that cannot DMA to unaligned addresses like
+4*n+2 or non-ethernet hardware, this can be a problem, and it is then
+required to copy the incoming frame into an aligned buffer. Because this is
+unnecessary on architectures that can do unaligned accesses, the code can be
+made depend on CONFIG_ARCH_CAN_UNALIGNED_ACCESS like so:
+
+#ifdef CONFIG_ARCH_CAN_UNALIGNED_ACCESS
+ skb = copy skb
+#else
+ skb = original skb
+#endif
+
--
-Author: Daniel Drake <[email protected]>
+Authors: Daniel Drake <[email protected]>,
+ Johannes Berg <[email protected]>
With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
-Johannes Berg, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock,
-Uli Kunitz, Vadim Lobanov
+Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz,
+Vadim Lobanov
--- everything.orig/arch/powerpc/Kconfig 2008-03-20 15:17:50.000000000 +0100
+++ everything/arch/powerpc/Kconfig 2008-03-20 15:19:00.000000000 +0100
@@ -84,6 +84,9 @@ config GENERIC_FIND_NEXT_BIT
config ARCH_NO_VIRT_TO_BUS
def_bool PPC64
+config ARCH_CAN_UNALIGNED_ACCESS
+ def_bool y
+
config PPC
bool
default y
--- everything.orig/arch/x86/Kconfig 2008-03-20 15:29:31.000000000 +0100
+++ everything/arch/x86/Kconfig 2008-03-20 15:29:49.000000000 +0100
@@ -144,6 +144,9 @@ config AUDIT_ARCH
config ARCH_SUPPORTS_AOUT
def_bool y
+config ARCH_CAN_UNALIGNED_ACCESS
+ def_bool y
+
# Use the generic interrupt handling code in kernel/irq/:
config GENERIC_HARDIRQS
bool
On Thu, Mar 20, 2008 at 03:34:55PM +0100, Johannes Berg wrote:
> In many cases, especially in networking, it can be beneficial to
> know at compile time whether the architecture can do unaligned
> accesses. This patch introduces a new Kconfig symbol
> ARCH_CAN_UNALIGNED_ACCESS
Can we please have a single symbol defined and name it:
HAVE_*
Then the architectures that HAVE this feature can select the symbol.
So somewhere in maybe lib/Kconfig or maybe arch/Kconfig add:
config HAVE_UNALIGNED_ACCESS_SUPPORT
bool
And then for x86 select the symbol:
config X86
+ select HAVE_UNALIGNED_ACCESS_SUPPORT
This follows the suggestion as available in
Documentation/kbuild/kconfig-language.txt
Sam
In many cases, especially in networking, it can be beneficial to
know at compile time whether the architecture can do unaligned
accesses efficiently. This patch introduces a new Kconfig symbol
HAVE_EFFICIENT_UNALIGNED_ACCESS
for that purpose and adds it to the powerpc and x86 architectures.
Also add some documentation about alignment and networking, and
especially one intended use of this symbol.
Signed-off-by: Johannes Berg <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Acked-by: Ingo Molnar <[email protected]> [x86 architecture part]
---
v5: rename to HAVE_EFFICIENT_UNALIGNED_ACCESS
I have opted to not introduce any symbol associated with the cost
of unaligned accesses, David Woodhouse once suggested that such a
cost should be combined with a probability of (un-)alignment even
in the get_unaligned/put_unaligned macros and I think this should
be combined with a patch introducing a global cost constant.
Also, this would require architecture changes because if some code
knew the likelyhood of unaligned accesses was small enough over
the cost of them, architectures that complain in the trap handle
would still complain in that unlikely case although the code
explicitly made a trade-off based on the cost/probability.
Documentation/unaligned-memory-access.txt | 32 +++++++++++++++++++++++++++---
arch/Kconfig | 19 +++++++++++++++++
arch/powerpc/Kconfig | 1
arch/x86/Kconfig | 1
4 files changed, 50 insertions(+), 3 deletions(-)
--- everything.orig/Documentation/unaligned-memory-access.txt 2008-03-25 14:54:11.000000000 +0100
+++ everything/Documentation/unaligned-memory-access.txt 2008-03-25 14:58:57.000000000 +0100
@@ -218,9 +218,35 @@ If use of such macros is not convenient,
where the source or destination (or both) are of type u8* or unsigned char*.
Due to the byte-wise nature of this operation, unaligned accesses are avoided.
+
+Alignment vs. Networking
+========================
+
+On architectures that require aligned loads, networking requires that the IP
+header is aligned on a four-byte boundary to optimise the IP stack. For
+regular ethernet hardware, the constant NET_IP_ALIGN is used, on most
+architectures this constant has the value 2 because the normal ethernet
+header is 14 bytes long, so in order to get proper alignment one needs to
+DMA to an address that is can be expressed as 4*n + 2. One notable exception
+here is powerpc which defines NET_IP_ALIGN to 0 because DMA to unaligned
+addresses can be very expensive and dwarf the cost of unaligned loads.
+
+For some ethernet hardware that cannot DMA to unaligned addresses like
+4*n+2 or non-ethernet hardware, this can be a problem, and it is then
+required to copy the incoming frame into an aligned buffer. Because this is
+unnecessary on architectures that can do unaligned accesses, the code can be
+made depend on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS like so:
+
+#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+ skb = original skb
+#else
+ skb = copy skb
+#endif
+
--
-Author: Daniel Drake <[email protected]>
+Authors: Daniel Drake <[email protected]>,
+ Johannes Berg <[email protected]>
With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
-Johannes Berg, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock,
-Uli Kunitz, Vadim Lobanov
+Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz,
+Vadim Lobanov
--- everything.orig/arch/powerpc/Kconfig 2008-03-25 14:54:10.000000000 +0100
+++ everything/arch/powerpc/Kconfig 2008-03-25 14:58:30.000000000 +0100
@@ -91,6 +91,7 @@ config PPC
select HAVE_OPROFILE
select HAVE_KPROBES
select HAVE_KRETPROBES
+ select HAVE_EFFICIENT_UNALIGNED_ACCESS
config EARLY_PRINTK
bool
--- everything.orig/arch/x86/Kconfig 2008-03-25 14:54:10.000000000 +0100
+++ everything/arch/x86/Kconfig 2008-03-25 14:58:38.000000000 +0100
@@ -23,6 +23,7 @@ config X86
select HAVE_KPROBES
select HAVE_KRETPROBES
select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
+ select HAVE_EFFICIENT_UNALIGNED_ACCESS
config GENERIC_LOCKBREAK
--- everything.orig/arch/Kconfig 2008-03-25 14:54:10.000000000 +0100
+++ everything/arch/Kconfig 2008-03-25 15:08:06.000000000 +0100
@@ -36,3 +36,22 @@ config HAVE_KPROBES
config HAVE_KRETPROBES
def_bool n
+
+config HAVE_EFFICIENT_UNALIGNED_ACCESS
+ def_bool n
+ help
+ Some architectures are unable to perform unaligned accesses
+ without the use of get_unaligned/put_unaligned. Others are
+ unable to perform such accesses efficiently (e.g. trap on
+ unaligned access and require fixing it up in the exception
+ handler.)
+
+ This symbol should be selected by an architecture if it can
+ perform unaligned accesses efficiently to allow different
+ code paths to be selected for these cases. Some network
+ drivers, for example, could opt to not fix up alignment
+ problems with received packets if doing so would not help
+ much.
+
+ See Documentation/unaligned-memory-access.txt for more
+ information on the topic of unaligned memory accesses.
* Johannes Berg <[email protected]> wrote:
> --- everything.orig/arch/x86/Kconfig 2008-03-20 15:30:38.000000000 +0100
> +++ everything/arch/x86/Kconfig 2008-03-20 19:38:08.000000000 +0100
> @@ -23,6 +23,7 @@ config X86
> select HAVE_KPROBES
> select HAVE_KRETPROBES
> select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
> + select HAVE_UNALIGNED_ACCESS_SUPPORT
Acked-by: Ingo Molnar <[email protected]>
Ingo
On Thu, 2008-03-20 at 14:39 +0000, Will Newton wrote:
> On Thu, Mar 20, 2008 at 2:34 PM, Johannes Berg
> <[email protected]> wrote:
>
> > +For some ethernet hardware that cannot DMA to unaligned addresses like
> > +4*n+2 or non-ethernet hardware, this can be a problem, and it is then
> > +required to copy the incoming frame into an aligned buffer. Because this is
> > +unnecessary on architectures that can do unaligned accesses, the code can be
> > +made depend on CONFIG_ARCH_CAN_UNALIGNED_ACCESS like so:
> > +
> > +#ifdef CONFIG_ARCH_CAN_UNALIGNED_ACCESS
> > + skb = copy skb
> > +#else
> > + skb = original skb
> > +#endif
>
> Is this logic reversed?
Euh, indeed, thanks. Will repost after having more comments.
johannes
> > +#ifdef CONFIG_HAVE_UNALIGNED_ACCESS_SUPPORT
> > + skb = original skb
> > +#else
> > + skb = copy skb
> > +#endif
> > +
>
> Couldn't this just be made an inline in a networking header somewhere,
> instead of ifdefs in the code?
That was just an example, you might want to do other things too. If it
turns out that a similar code pattern will be used all over the place we
can then consolidate that.
johannes
> I think you're semantically testing the wrong thing.
>
> It's not if unaligned accesses are supported, it's if they are
> efficient enough or not.
>
> For example, sparc64 fully handles unaligned accesses but taking the
> trap to fix it up is slow. So sparc64 "can" handle unaligned
> accesses, but whether we want to set this symbol or not is another
> matter.
Yeah, good point. Should I rename it to HAVE_EFFICIENT_UNALIGNED_ACCESS
or similar? Or have it defined as some sort of number so you can make
actually make tradeoffs? Like Dave Woodhouse suggested at some point to
have get_unaligned() take an argument that indicates the probability...
johannes
On Thu, Mar 20, 2008 at 10:21:46PM +0100, Johannes Berg wrote:
>
> > I think you're semantically testing the wrong thing.
> >
> > It's not if unaligned accesses are supported, it's if they are
> > efficient enough or not.
> >
> > For example, sparc64 fully handles unaligned accesses but taking the
> > trap to fix it up is slow. So sparc64 "can" handle unaligned
> > accesses, but whether we want to set this symbol or not is another
> > matter.
>
> Yeah, good point. Should I rename it to HAVE_EFFICIENT_UNALIGNED_ACCESS
> or similar? Or have it defined as some sort of number so you can make
> actually make tradeoffs? Like Dave Woodhouse suggested at some point to
> have get_unaligned() take an argument that indicates the probability...
Ugh...that sounds like premature optimization to me...
While I think Dave has a point, I don't think you should labor the word
choice too much. Try to document it as clearly as possible and hope
for the best -- I hear that the arch maintainers are top notch! :-)
John
--
John W. Linville
[email protected]
From: "John W. Linville" <[email protected]>
Date: Thu, 20 Mar 2008 18:03:48 -0400
> While I think Dave has a point, I don't think you should labor the word
> choice too much. Try to document it as clearly as possible and hope
> for the best -- I hear that the arch maintainers are top notch! :-)
I think the name of the macro is very important.
Non-arch people will see this thing and wonder what in the
world it means. You can document something with kerneldoc
foo as much as you like, still the initial impression the
reader gets from the name is of utmost importance.
In many cases, especially in networking, it can be beneficial to
know at compile time whether the architecture can do unaligned
accesses. This patch introduces a new Kconfig symbol
HAVE_UNALIGNED_ACCESS_SUPPORT
for that purpose and adds it to the powerpc and x86 architectures.
Also add some documentation about alignment and networking, and
especially one intended use of this symbol.
Signed-off-by: Johannes Berg <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
---
Didn't I say I was going to fix the subject? Sorry.
Documentation/unaligned-memory-access.txt | 32 +++++++++++++++++++++++++++---
arch/Kconfig | 3 ++
arch/powerpc/Kconfig | 1
arch/x86/Kconfig | 1
4 files changed, 34 insertions(+), 3 deletions(-)
--- everything.orig/Documentation/unaligned-memory-access.txt 2008-03-20 15:30:38.000000000 +0100
+++ everything/Documentation/unaligned-memory-access.txt 2008-03-20 19:38:30.000000000 +0100
@@ -218,9 +218,35 @@ If use of such macros is not convenient,
where the source or destination (or both) are of type u8* or unsigned char*.
Due to the byte-wise nature of this operation, unaligned accesses are avoided.
+
+Alignment vs. Networking
+========================
+
+On architectures that require aligned loads, networking requires that the IP
+header is aligned on a four-byte boundary to optimise the IP stack. For
+regular ethernet hardware, the constant NET_IP_ALIGN is used, on most
+architectures this constant has the value 2 because the normal ethernet
+header is 14 bytes long, so in order to get proper alignment one needs to
+DMA to an address that is can be expressed as 4*n + 2. One notable exception
+here is powerpc which defines NET_IP_ALIGN to 0 because DMA to unaligned
+addresses can be very expensive and dwarf the cost of unaligned loads.
+
+For some ethernet hardware that cannot DMA to unaligned addresses like
+4*n+2 or non-ethernet hardware, this can be a problem, and it is then
+required to copy the incoming frame into an aligned buffer. Because this is
+unnecessary on architectures that can do unaligned accesses, the code can be
+made depend on CONFIG_HAVE_UNALIGNED_ACCESS_SUPPORT like so:
+
+#ifdef CONFIG_HAVE_UNALIGNED_ACCESS_SUPPORT
+ skb = original skb
+#else
+ skb = copy skb
+#endif
+
--
-Author: Daniel Drake <[email protected]>
+Authors: Daniel Drake <[email protected]>,
+ Johannes Berg <[email protected]>
With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
-Johannes Berg, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock,
-Uli Kunitz, Vadim Lobanov
+Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz,
+Vadim Lobanov
--- everything.orig/arch/powerpc/Kconfig 2008-03-20 15:30:38.000000000 +0100
+++ everything/arch/powerpc/Kconfig 2008-03-20 19:37:22.000000000 +0100
@@ -91,6 +91,7 @@ config PPC
select HAVE_OPROFILE
select HAVE_KPROBES
select HAVE_KRETPROBES
+ select HAVE_UNALIGNED_ACCESS_SUPPORT
config EARLY_PRINTK
bool
--- everything.orig/arch/x86/Kconfig 2008-03-20 15:30:38.000000000 +0100
+++ everything/arch/x86/Kconfig 2008-03-20 19:38:08.000000000 +0100
@@ -23,6 +23,7 @@ config X86
select HAVE_KPROBES
select HAVE_KRETPROBES
select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
+ select HAVE_UNALIGNED_ACCESS_SUPPORT
config GENERIC_LOCKBREAK
--- everything.orig/arch/Kconfig 2008-03-20 19:37:26.000000000 +0100
+++ everything/arch/Kconfig 2008-03-20 19:37:34.000000000 +0100
@@ -36,3 +36,6 @@ config HAVE_KPROBES
config HAVE_KRETPROBES
def_bool n
+
+config HAVE_UNALIGNED_ACCESS_SUPPORT
+ def_bool n
On Thu, 2008-03-20 at 19:13 +0100, Sam Ravnborg wrote:
> On Thu, Mar 20, 2008 at 03:34:55PM +0100, Johannes Berg wrote:
> > In many cases, especially in networking, it can be beneficial to
> > know at compile time whether the architecture can do unaligned
> > accesses. This patch introduces a new Kconfig symbol
> > ARCH_CAN_UNALIGNED_ACCESS
>
> Can we please have a single symbol defined and name it:
> HAVE_*
>
> Then the architectures that HAVE this feature can select the symbol.
Sure. Where should it be defined? arch/Kconfig?
> This follows the suggestion as available in
> Documentation/kbuild/kconfig-language.txt
Guess I haven't read that in a while.
johannes
On Thu, Mar 20, 2008 at 07:45:34PM +0100, Johannes Berg wrote:
> Subject: introduce HAVE_UNALIGNED_ACCESS_SUPPORT Kconfig symbol
>
> In many cases, especially in networking, it can be beneficial to
> know at compile time whether the architecture can do unaligned
> accesses. This patch introduces a new Kconfig symbol
> HAVE_UNALIGNED_ACCESS_SUPPORT
> for that purpose and adds it to the powerpc and x86 architectures.
> Also add some documentation about alignment and networking, and
> especially one intended use of this symbol.
>
> Signed-off-by: Johannes Berg <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Sam
From: Johannes Berg <[email protected]>
Date: Thu, 20 Mar 2008 22:21:46 +0100
> Yeah, good point. Should I rename it to HAVE_EFFICIENT_UNALIGNED_ACCESS
> or similar? Or have it defined as some sort of number so you can make
> actually make tradeoffs? Like Dave Woodhouse suggested at some point to
> have get_unaligned() take an argument that indicates the probability...
Yes, that name and something with a "score" of some sort would
be nice.
On Thu, 2008-03-20 at 19:45 +0100, Johannes Berg wrote:
> +For some ethernet hardware that cannot DMA to unaligned addresses like
> +4*n+2 or non-ethernet hardware, this can be a problem, and it is then
> +required to copy the incoming frame into an aligned buffer. Because this is
> +unnecessary on architectures that can do unaligned accesses, the code can be
> +made depend on CONFIG_HAVE_UNALIGNED_ACCESS_SUPPORT like so:
> +
> +#ifdef CONFIG_HAVE_UNALIGNED_ACCESS_SUPPORT
> + skb = original skb
> +#else
> + skb = copy skb
> +#endif
> +
Couldn't this just be made an inline in a networking header somewhere,
instead of ifdefs in the code?
Harvey
On Thu, Mar 20, 2008 at 2:34 PM, Johannes Berg
<[email protected]> wrote:
> +For some ethernet hardware that cannot DMA to unaligned addresses like
> +4*n+2 or non-ethernet hardware, this can be a problem, and it is then
> +required to copy the incoming frame into an aligned buffer. Because this is
> +unnecessary on architectures that can do unaligned accesses, the code can be
> +made depend on CONFIG_ARCH_CAN_UNALIGNED_ACCESS like so:
> +
> +#ifdef CONFIG_ARCH_CAN_UNALIGNED_ACCESS
> + skb = copy skb
> +#else
> + skb = original skb
> +#endif
Is this logic reversed?
From: Johannes Berg <[email protected]>
Date: Thu, 20 Mar 2008 19:39:33 +0100
> In many cases, especially in networking, it can be beneficial to
> know at compile time whether the architecture can do unaligned
> accesses. This patch introduces a new Kconfig symbol
> ARCH_CAN_UNALIGNED_ACCESS
> for that purpose and adds it to the powerpc and x86 architectures.
> Also add some documentation about alignment and networking, and
> especially one intended use of this symbol.
>
> Signed-off-by: Johannes Berg <[email protected]>
I think you're semantically testing the wrong thing.
It's not if unaligned accesses are supported, it's if they are
efficient enough or not.
For example, sparc64 fully handles unaligned accesses but taking the
trap to fix it up is slow. So sparc64 "can" handle unaligned
accesses, but whether we want to set this symbol or not is another
matter.
Subject: introduce HAVE_UNALIGNED_ACCESS_SUPPORT Kconfig symbol
In many cases, especially in networking, it can be beneficial to
know at compile time whether the architecture can do unaligned
accesses. This patch introduces a new Kconfig symbol
HAVE_UNALIGNED_ACCESS_SUPPORT
for that purpose and adds it to the powerpc and x86 architectures.
Also add some documentation about alignment and networking, and
especially one intended use of this symbol.
Signed-off-by: Johannes Berg <[email protected]>
---
Erm. I should update the patch description and title too...
Documentation/unaligned-memory-access.txt | 32 +++++++++++++++++++++++++++---
arch/Kconfig | 3 ++
arch/powerpc/Kconfig | 1
arch/x86/Kconfig | 1
4 files changed, 34 insertions(+), 3 deletions(-)
--- everything.orig/Documentation/unaligned-memory-access.txt 2008-03-20 15:30:38.000000000 +0100
+++ everything/Documentation/unaligned-memory-access.txt 2008-03-20 19:38:30.000000000 +0100
@@ -218,9 +218,35 @@ If use of such macros is not convenient,
where the source or destination (or both) are of type u8* or unsigned char*.
Due to the byte-wise nature of this operation, unaligned accesses are avoided.
+
+Alignment vs. Networking
+========================
+
+On architectures that require aligned loads, networking requires that the IP
+header is aligned on a four-byte boundary to optimise the IP stack. For
+regular ethernet hardware, the constant NET_IP_ALIGN is used, on most
+architectures this constant has the value 2 because the normal ethernet
+header is 14 bytes long, so in order to get proper alignment one needs to
+DMA to an address that is can be expressed as 4*n + 2. One notable exception
+here is powerpc which defines NET_IP_ALIGN to 0 because DMA to unaligned
+addresses can be very expensive and dwarf the cost of unaligned loads.
+
+For some ethernet hardware that cannot DMA to unaligned addresses like
+4*n+2 or non-ethernet hardware, this can be a problem, and it is then
+required to copy the incoming frame into an aligned buffer. Because this is
+unnecessary on architectures that can do unaligned accesses, the code can be
+made depend on CONFIG_HAVE_UNALIGNED_ACCESS_SUPPORT like so:
+
+#ifdef CONFIG_HAVE_UNALIGNED_ACCESS_SUPPORT
+ skb = original skb
+#else
+ skb = copy skb
+#endif
+
--
-Author: Daniel Drake <[email protected]>
+Authors: Daniel Drake <[email protected]>,
+ Johannes Berg <[email protected]>
With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
-Johannes Berg, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock,
-Uli Kunitz, Vadim Lobanov
+Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz,
+Vadim Lobanov
--- everything.orig/arch/powerpc/Kconfig 2008-03-20 15:30:38.000000000 +0100
+++ everything/arch/powerpc/Kconfig 2008-03-20 19:37:22.000000000 +0100
@@ -91,6 +91,7 @@ config PPC
select HAVE_OPROFILE
select HAVE_KPROBES
select HAVE_KRETPROBES
+ select HAVE_UNALIGNED_ACCESS_SUPPORT
config EARLY_PRINTK
bool
--- everything.orig/arch/x86/Kconfig 2008-03-20 15:30:38.000000000 +0100
+++ everything/arch/x86/Kconfig 2008-03-20 19:38:08.000000000 +0100
@@ -23,6 +23,7 @@ config X86
select HAVE_KPROBES
select HAVE_KRETPROBES
select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
+ select HAVE_UNALIGNED_ACCESS_SUPPORT
config GENERIC_LOCKBREAK
--- everything.orig/arch/Kconfig 2008-03-20 19:37:26.000000000 +0100
+++ everything/arch/Kconfig 2008-03-20 19:37:34.000000000 +0100
@@ -36,3 +36,6 @@ config HAVE_KPROBES
config HAVE_KRETPROBES
def_bool n
+
+config HAVE_UNALIGNED_ACCESS_SUPPORT
+ def_bool n
In many cases, especially in networking, it can be beneficial to
know at compile time whether the architecture can do unaligned
accesses. This patch introduces a new Kconfig symbol
ARCH_CAN_UNALIGNED_ACCESS
for that purpose and adds it to the powerpc and x86 architectures.
Also add some documentation about alignment and networking, and
especially one intended use of this symbol.
Signed-off-by: Johannes Berg <[email protected]>
---
Fixes thanks to Sam and Will.
Documentation/unaligned-memory-access.txt | 32 +++++++++++++++++++++++++++---
arch/Kconfig | 3 ++
arch/powerpc/Kconfig | 1
arch/x86/Kconfig | 1
4 files changed, 34 insertions(+), 3 deletions(-)
--- everything.orig/Documentation/unaligned-memory-access.txt 2008-03-20 15:30:38.000000000 +0100
+++ everything/Documentation/unaligned-memory-access.txt 2008-03-20 19:38:30.000000000 +0100
@@ -218,9 +218,35 @@ If use of such macros is not convenient,
where the source or destination (or both) are of type u8* or unsigned char*.
Due to the byte-wise nature of this operation, unaligned accesses are avoided.
+
+Alignment vs. Networking
+========================
+
+On architectures that require aligned loads, networking requires that the IP
+header is aligned on a four-byte boundary to optimise the IP stack. For
+regular ethernet hardware, the constant NET_IP_ALIGN is used, on most
+architectures this constant has the value 2 because the normal ethernet
+header is 14 bytes long, so in order to get proper alignment one needs to
+DMA to an address that is can be expressed as 4*n + 2. One notable exception
+here is powerpc which defines NET_IP_ALIGN to 0 because DMA to unaligned
+addresses can be very expensive and dwarf the cost of unaligned loads.
+
+For some ethernet hardware that cannot DMA to unaligned addresses like
+4*n+2 or non-ethernet hardware, this can be a problem, and it is then
+required to copy the incoming frame into an aligned buffer. Because this is
+unnecessary on architectures that can do unaligned accesses, the code can be
+made depend on CONFIG_HAVE_UNALIGNED_ACCESS_SUPPORT like so:
+
+#ifdef CONFIG_HAVE_UNALIGNED_ACCESS_SUPPORT
+ skb = original skb
+#else
+ skb = copy skb
+#endif
+
--
-Author: Daniel Drake <[email protected]>
+Authors: Daniel Drake <[email protected]>,
+ Johannes Berg <[email protected]>
With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
-Johannes Berg, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock,
-Uli Kunitz, Vadim Lobanov
+Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz,
+Vadim Lobanov
--- everything.orig/arch/powerpc/Kconfig 2008-03-20 15:30:38.000000000 +0100
+++ everything/arch/powerpc/Kconfig 2008-03-20 19:37:22.000000000 +0100
@@ -91,6 +91,7 @@ config PPC
select HAVE_OPROFILE
select HAVE_KPROBES
select HAVE_KRETPROBES
+ select HAVE_UNALIGNED_ACCESS_SUPPORT
config EARLY_PRINTK
bool
--- everything.orig/arch/x86/Kconfig 2008-03-20 15:30:38.000000000 +0100
+++ everything/arch/x86/Kconfig 2008-03-20 19:38:08.000000000 +0100
@@ -23,6 +23,7 @@ config X86
select HAVE_KPROBES
select HAVE_KRETPROBES
select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
+ select HAVE_UNALIGNED_ACCESS_SUPPORT
config GENERIC_LOCKBREAK
--- everything.orig/arch/Kconfig 2008-03-20 19:37:26.000000000 +0100
+++ everything/arch/Kconfig 2008-03-20 19:37:34.000000000 +0100
@@ -36,3 +36,6 @@ config HAVE_KPROBES
config HAVE_KRETPROBES
def_bool n
+
+config HAVE_UNALIGNED_ACCESS_SUPPORT
+ def_bool n
On Tue, 2008-03-25 at 15:11 +0100, Johannes Berg wrote:
> In many cases, especially in networking, it can be beneficial to
> know at compile time whether the architecture can do unaligned
> accesses efficiently. This patch introduces a new Kconfig symbol
> HAVE_EFFICIENT_UNALIGNED_ACCESS
> for that purpose and adds it to the powerpc and x86 architectures.
> Also add some documentation about alignment and networking, and
> especially one intended use of this symbol.
I haven't had comments on this last version, any objections to sending
it to akpm for inclusion? I would like to start building on it in the
wireless tree.
Also, what's the best way to get arch maintainers to note this and
evaluate whether they want to set the symbol or not?
johannes