Date: Mon, 30 Jun 2014 20:02:03 +0200 From: Bernd Walter <ticso@cicely7.cicely.de> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arm@freebsd.org" <arm@freebsd.org>, ticso@cicely.de Subject: Re: arm alignment faults... Message-ID: <20140630180203.GE55631@cicely7.cicely.de> In-Reply-To: <31EF05A5-0886-4F5C-97BB-2EF749533633@bsdimp.com> References: <20140629033823.GN1560@funkthat.com> <CAJ-VmokxO5vfOOSvPrTfnda6gSKOPpJQF3kto3AdgUhvbFgNYg@mail.gmail.com> <20140629040150.GO1560@funkthat.com> <CAJ-Vmon1iFeJdJ-nBnz%2B4bqannshT4nct2dFKep1EZzCEM62Jw@mail.gmail.com> <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> <20140629054039.GP1560@funkthat.com> <039F8A84-0193-424C-8093-E411957817E9@bsdimp.com> <20140630131126.GB55631@cicely7.cicely.de> <31EF05A5-0886-4F5C-97BB-2EF749533633@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 30, 2014 at 11:41:25AM -0600, Warner Losh wrote: > > On Jun 30, 2014, at 7:11 AM, Bernd Walter <ticso@cicely7.cicely.de> wrote: > > > On Sun, Jun 29, 2014 at 10:33:59AM -0600, Warner Losh wrote: > >> > >> On Jun 28, 2014, at 11:40 PM, John-Mark Gurney <jmg@funkthat.com> wrote: > >> > >>> Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600: > >>>> > >>>> On Jun 28, 2014, at 10:52 PM, Adrian Chadd <adrian@freebsd.org> wrote: > >>>> > >>>>> On 28 June 2014 21:01, John-Mark Gurney <jmg@funkthat.com> wrote: > >>>>>> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700: > >>>>>>> On 28 June 2014 20:38, John-Mark Gurney <jmg@funkthat.com> wrote: > >>>>>>>> So, one of the little projects I'd like to see is the removal of > >>>>>>>> ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use > >>>>>>>> of bouncing durning DMA ops on all ethernet frames... > >>>>>> > >>>>>> Now that I think about it, total removal may not be necessary, just > >>>>>> the requirement to use it... If the ethernet dma engine can do half > >>>>>> word aligned dma, then there would be benifit on those to keep > >>>>>> ETHER_ALIGN... > >>>>>> > >>>>>>> Well, as long as you're not doing it by forcing the various CPUs to > >>>>>>> handle unaligned accesses. > >>>>>> > >>>>>> Hard to do on armv4 which I don't believe supports unaligned access... > >>>>>> > >>>>>>> The cost of those unaligned accesses on some CPUs that support them is > >>>>>>> not trivial. We benchmarked some of the ARM cores at Qualcomm back > >>>>>>> when looking to migrate stuff to ARM and it wasn't very quick. > >>>>>> > >>>>>> I plan on fixing the TCP/IP stack to copy data to an aligned buffer > >>>>>> (maybe only if the original buffer isn't aligned) on the stack when > >>>>>> __NO_STRICT_ALIGNMENT is not defined... I can't see how copying the > >>>>>> entire packet is cheaper than copying 20 bytes or so... > >>>>> > >>>>> There's lots of other stupid corner cases that screw you. > >>>>> > >>>>> VLAN headers add extra bytes. > >>>>> > >>>>> 802.11 headers can offset things depending upon the 802.11 frame type > >>>>> (3-addr, 4-addr, vlan, no vlan, etc.) > >>>>> > >>>>> There's no guarantee all ethernet DMA engines can do the alignment as > >>>>> required. :( > >>>> > >>>> The ate driver for Atmel?s AT91RM9200 is one such beast. > >>> > >>> Are you sure? The tag for data says alignment 1: > >>> if (bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0, > >>> BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES, > >>> 1, MCLBYTES, 0, busdma_lock_mutex, &sc->sc_mtx, &sc->mtag)) > >>> > >>> Or is that a limitation on the parent? > >> > >> It is a limitation in hardware. You have to DMA to a 4 byte boundary. That might be a bug in the above line though? > > > > It is a limitation of the AT91RM9200. > > More recent ate hardware (e.g. AT91SAM9260) don't have this limitation. > > Yea, the problem is that the packet has to start on a % 4 == 0boundary, which means the ether header is aligned, but nothing else in the IP header is aligned, so bad things happen. The lame thing we did in the ate driver was to copy the whole packet. A smarter thing to do would be to just do a m_pullup() of the IP header. The even smarter thing to do is to limit this to the AT91RM9200, or make the ate driver at91rm9200 only and fix the macb(4) driver which currently doesn?t work at all for the boards I have. On the SAM9 SoCs we can do a smart thing and have the DMA start % 4 == 2, which naturally aligns the headers that are assumed to be naturally aligned, at least in the NFS root boot code (which IIRC was the only thing I hit where any of this matters). Worse of all I had been using a switch chip with VLAN trunk to the RM9200. However those boards worked fine besides of several hardware drawbacks on the RM9200. One of those boards is still running my home automation with amazing 1283 days uptime. In the meantime I'm trying to switch over to Wandboard Modules. If anyone needs a GNU PCB EDM header footprint for vendor supplied Foxconn sockets, just mail me. I've done one last week, but it is not tested in real hardware so far. -- B.Walter <bernd@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140630180203.GE55631>