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 <johannes@sipsolutions.net>

---

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 int...
[ message continues ]

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. 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 <johannes@sipsolutions.net>

---

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 ...
[ message continues ]

From: Johannes Berg <johannes@sipsolutions.net>
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.

--

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 <johannes@sipsolutions.net>

Acked-by: Sam Ravnborg <sam@ravnborg.org>

Acked-by: Ingo Molnar <mingo@elte.hu> [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. N...
[ message continues ]

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

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

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

linville@tuxdriver.com

--

From: "John W. Linville" <linville@tuxdriver.com>
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.

--

From: Johannes Berg <johannes@sipsolutions.net>
Yes, that name and something with a "score" of some sort would

be nice.
--

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 <johannes@sipsolutions.net>

---

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...
[ message continues ]

Acked-by: Sam Ravnborg <sam@ravnborg.org>
	Sam
--

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 <johannes@sipsolutions.net>

Acked-by: Sam Ravnborg <sam@ravnborg.org>

---

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 hardw...
[ message continues ]

Acked-by: Ingo Molnar <mingo@elte.hu>
	Ingo

--

Couldn't this just be made an inline in a networking header somewhere,

instead of ifdefs in the code?
Harvey
--

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

Guess I haven't read that in a while.
johannes

On Thu, Mar 20, 2008 at 2:34 PM, Johannes Berg
Is this logic reversed?

--

Euh, indeed, thanks. Will repost after having more comments.
johannes