Date: Mon, 30 Jun 2014 11:41:25 -0600 From: Warner Losh <imp@bsdimp.com> To: ticso@cicely.de Cc: "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: Re: arm alignment faults... Message-ID: <31EF05A5-0886-4F5C-97BB-2EF749533633@bsdimp.com> In-Reply-To: <20140630131126.GB55631@cicely7.cicely.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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: >>=20 >> On Jun 28, 2014, at 11:40 PM, John-Mark Gurney <jmg@funkthat.com> = wrote: >>=20 >>> Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600: >>>>=20 >>>> On Jun 28, 2014, at 10:52 PM, Adrian Chadd <adrian@freebsd.org> = wrote: >>>>=20 >>>>> 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... >>>>>>=20 >>>>>> 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... >>>>>>=20 >>>>>>> Well, as long as you're not doing it by forcing the various CPUs = to >>>>>>> handle unaligned accesses. >>>>>>=20 >>>>>> Hard to do on armv4 which I don't believe supports unaligned = access... >>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> 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... >>>>>=20 >>>>> There's lots of other stupid corner cases that screw you. >>>>>=20 >>>>> VLAN headers add extra bytes. >>>>>=20 >>>>> 802.11 headers can offset things depending upon the 802.11 frame = type >>>>> (3-addr, 4-addr, vlan, no vlan, etc.) >>>>>=20 >>>>> There's no guarantee all ethernet DMA engines can do the alignment = as >>>>> required. :( >>>>=20 >>>> The ate driver for Atmel?s AT91RM9200 is one such beast. >>>=20 >>> 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)) >>>=20 >>> Or is that a limitation on the parent? >>=20 >> 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? >=20 > 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 =3D=3D = 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=92t work at all = for the boards I have. On the SAM9 SoCs we can do a smart thing and have = the DMA start % 4 =3D=3D 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). Warner --Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTsaFFAAoJEGwc0Sh9sBEAFDIP/2CD46M1/Utd827ZghHHxJRW AeH/MDqx9oDzxgdt0WFfOTa9WK8Got3QHmgPCnLRb3jB/d8XHe1g3ElNK5LkyviK 7UDt38I+pU8ICbJNRGWnE3nyMYY9FB+0WHUBsfJYYJLFfF8ZfDnhWXCxvOGvaQsX Ew8AhJ6FQFrNZR8ifZVZBroJTg89MLKhp9MeLIeNjdHR4yo5uri8cmOt4mkfujsy hw5L+CduCThYUD/wO4mZ0Lj0xKbpwTF+uiX9qK+QDF7COiWXC98qpntjmfh3AXOE S0qZTZ8aq7J4r6Nc4CjhUOAX7PeM2Idy53lDpo8AfPbM5tL2xz/23/nztKM8+1Uk 8clS82NCveUCW/4ijvyXdDS8GAkhIXjZfA1TzL5yTOiaRCMD6neEi/heDi9xxJQA wD6F7uLONguMBK3nQhZiQqdIaly0jQjjo4dndm26E8wK3LKGXyLrGI3QySyI6nU8 pbNsvavq8awboBnU8OLP5JgfeRN6kD50CcRvbXruSFP5D887IBYt+HKcF8bMm578 j4Y6ae1VNjbSbu0zFaqHRvzB9EQSNlcM3XMT2GvnauwNSai7fB+PAo3pfKI1Afsn 86Yq4r6HEf9V4Hxn+WX3c6iO0uvDnGYjs+9cdpjqEtS/PQQcpkOzBMQkI2am8Mmt KYIrPS1y7lEe3gn42hoj =pPNx -----END PGP SIGNATURE----- --Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31EF05A5-0886-4F5C-97BB-2EF749533633>