netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: David Miller <davem@davemloft.net>
Cc: sam@ravnborg.org, dsd@gentoo.org, linux-kernel@vger.kernel.org,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	Ingo Molnar <mingo@elte.hu>,
	David Woodhouse <dwmw2@infradead.org>
Subject: [PATCH/RFC v5] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS Kconfig symbol
Date: Tue, 25 Mar 2008 15:11:42 +0100	[thread overview]
Message-ID: <1206454302.16475.269.camel@johannes.berg> (raw)
In-Reply-To: <20080320.141307.173590705.davem@davemloft.net>

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. 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 <dsd@gentoo.org>
+Authors: Daniel Drake <dsd@gentoo.org>,
+         Johannes Berg <johannes@sipsolutions.net>
 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.



  parent reply	other threads:[~2008-03-25 15:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-20 14:34 [PATCH/RFC] introduce ARCH_CAN_UNALIGNED_ACCESS Kconfig symbol Johannes Berg
     [not found] ` <1206023695.16475.137.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
2008-03-20 14:39   ` Will Newton
     [not found]     ` <87a5b0800803200739v6d222afck850f221eae1edd70-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-03-20 14:58       ` Johannes Berg
2008-03-20 18:13 ` Sam Ravnborg
     [not found]   ` <20080320181310.GA17884-QabhHTsIXMSnlFQ6Q1D1Y0B+6BGkLq7r@public.gmane.org>
2008-03-20 18:35     ` Johannes Berg
2008-03-20 18:39   ` [PATCH/RFC v2] " Johannes Berg
     [not found]     ` <1206038373.16475.150.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
2008-03-20 18:45       ` [PATCH/RFC v3] " Johannes Berg
2008-03-20 19:09         ` Harvey Harrison
2008-03-20 19:12           ` Johannes Berg
     [not found]         ` <1206038734.16475.153.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
2008-03-20 19:41           ` Sam Ravnborg
     [not found]             ` <20080320194101.GC17884-QabhHTsIXMSnlFQ6Q1D1Y0B+6BGkLq7r@public.gmane.org>
2008-03-20 19:50               ` [PATCH/RFC v4] introduce HAVE_UNALIGNED_ACCESS_SUPPORT " Johannes Berg
2008-03-21  8:45                 ` Ingo Molnar
2008-03-20 21:13     ` [PATCH/RFC v2] introduce ARCH_CAN_UNALIGNED_ACCESS " David Miller
     [not found]       ` <20080320.141307.173590705.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-03-20 21:21         ` Johannes Berg
     [not found]           ` <1206048106.16475.161.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
2008-03-20 21:27             ` David Miller
2008-03-20 22:03             ` John W. Linville
     [not found]               ` <20080320220348.GC1330-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
2008-03-20 22:10                 ` David Miller
2008-03-25 14:11       ` Johannes Berg [this message]
     [not found]         ` <1206454302.16475.269.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
2008-04-02 10:24           ` [PATCH/RFC v5] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS " Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1206454302.16475.269.camel@johannes.berg \
    --to=johannes@sipsolutions.net \
    --cc=davem@davemloft.net \
    --cc=dsd@gentoo.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.org \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).