From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 05:40:42 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56FB2572; Sun, 29 Jun 2014 05:40:42 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 324D229A6; Sun, 29 Jun 2014 05:40:41 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5T5edw6007510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jun 2014 22:40:39 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5T5edDA007509; Sat, 28 Jun 2014 22:40:39 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Jun 2014 22:40:39 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: arm alignment faults... Message-ID: <20140629054039.GP1560@funkthat.com> Mail-Followup-To: Warner Losh , Adrian Chadd , "freebsd-arm@freebsd.org" References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 28 Jun 2014 22:40:40 -0700 (PDT) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 05:40:42 -0000 Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600: > > On Jun 28, 2014, at 10:52 PM, Adrian Chadd wrote: > > > On 28 June 2014 21:01, John-Mark Gurney wrote: > >> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700: > >>> On 28 June 2014 20:38, John-Mark Gurney 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? I did an audit of the arm drivers (not mips), but I didn't see any that have the restriction... The one that I'm thinking of was the Cirrus EP9302 in the TS-7200 port that I did years ago.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."