[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161001195215.GP1041@n2100.armlinux.org.uk>
Date: Sat, 1 Oct 2016 20:52:15 +0100
From: Russell King - ARM Linux <linux@...linux.org.uk>
To: Eric Nelson <eric@...int.com>
Cc: David Laight <David.Laight@...LAB.COM>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"andrew@...n.ch" <andrew@...n.ch>,
"fugang.duan@....com" <fugang.duan@....com>,
"otavio@...ystems.com.br" <otavio@...ystems.com.br>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"troy.kisky@...ndarydevices.com" <troy.kisky@...ndarydevices.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>
Subject: Re: [PATCH 3/3] net: fec: align IP header in hardware
On Fri, Sep 30, 2016 at 07:16:12AM -0700, Eric Nelson wrote:
> On ARM, the CPU can't handle misaligned memory cycles without
> taking an alignment fault and NET_IP_ALIGN is set to 2.
Let's get this right... With Linux on MMU parts:
On ARMv6+, unaligned memory cycles using the LDR, LDRH and corresponding
store instructions are handled in hardware without any exception being
raised.
On pre-ARMv6, such instructions raise an alignment exception, and we fix
up the load/store manually.
Where things behave the same is with the LDM (load multiple) and STM
(store multiple) instructions. Hardware does not fix these up if they
are unaligned: it is expected that the base address will always be
aligned to a 32-bit word.
For some reason, the compiler guys have decided it's okay to use these
instructions as an optimisation, and I see no way to disable this
behaviour.
> On ARM, we have CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
> but I find it hard to believe that taking alignment faults is more
> efficient than adding two bytes to the start of the frame.
... see above, hence why CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set.
It's only when the compiler decides to do silly things that things go
wrong. However, net code does not care about that configuration
setting, so it's irrelevant to this discussion.
The issue with the networking layer is that it passes around structure
pointers which may not be "naturally aligned" - technically it goes
against the C standard specs. However, you'll find it hard to argue
against this, so we have to accept that the networking people expect
it to work.
The optimisation that the C compiler uses (using LDM to access multiple
32-bit consecutive words) is legal and efficient when the structure
pointers are aligned as it expects, but that all breaks if the pointer
is not so aligned. So, raising it as a bug against the C compiler isn't
going to work either.
What may work is to raise a feature request with compiler people to have
a mechanism to disable the LDM/STM optimisation for code where we know
that pointers may not be naturally aligned.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Powered by blists - more mailing lists