arm alignment faults...

[John-Mark Gurney]

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 at freebsd.org> wrote:
> 
> > On 28 June 2014 21:01, John-Mark Gurney <jmg at 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 at 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?

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."