Date: Sat, 28 Jun 2014 22:53:37 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: Re: arm alignment faults... Message-ID: <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> In-Reply-To: <CAJ-Vmon1iFeJdJ-nBnz%2B4bqannshT4nct2dFKep1EZzCEM62Jw@mail.gmail.com> References: <20140629033823.GN1560@funkthat.com> <CAJ-VmokxO5vfOOSvPrTfnda6gSKOPpJQF3kto3AdgUhvbFgNYg@mail.gmail.com> <20140629040150.GO1560@funkthat.com> <CAJ-Vmon1iFeJdJ-nBnz%2B4bqannshT4nct2dFKep1EZzCEM62Jw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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. Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTr5vSAAoJEGwc0Sh9sBEAxMAQAJ8fOipAInrkGmn/EDLSVlbR FDJfXVW03PIlMFs8dC43dTIi2sbBQ/q90v6ByCveYIRXQn5D+yQykDgF01VUlJOw cFHPyn/Emm68NwX8uhjKgGaGEuNIoEo0pH8L9vfBItSqMcN6J9qAIP0tXjk4r3ZQ BvZNl+B6M9sfbh3NG97a4v+N9FqWohdVBKnzZ4mxGCzBOPigxuFQgf5EkAKR6/By M1lJ7P57ro+8iIXxQg8QXwKtkwPINBX4HoMF2V2Md1LRQuC8VWGzxmSbWOlXbiUz 4sQyx08iYRLRl8hpg21Jx6uOQa78dy9fwRuZA+XbvYT36Ks1MxMqlHeeW0jqYjOA JPKkrjCXhD1T6K8fTE0IAck2Z8+xItB18M51xaP1l3StJCvPiD0POeuKWdJGbO44 VtQi/zv4TlxQnBB8OMHn4JGCSUr/KEIuzg2DqCtifisKhUaHAQnHoW+tC1ShWGTK Qnlji/VpNuzeGzvBOvAsWd24kofD82JUOQBlsacvPddVu/K02cw5rJTuvd/ev/lD X+G/Ul/DsDLTzI3yvk32X7wayFxTKdHYe8iFHL5rPi8Ysn/R1P+ueaaTMF4cz7ww 5nlYNZ/EHCL/E3BjJKr0gXLCB34pCrReuoo8/EIQMZRgHN612f0PqxUOwX0gjdhv qog5XtQ26LuAvG3krbOJ =WNRz -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86E20F1C-C161-45B2-AC82-11738596E004>