MFC r228325:

MFC r228325:
  Overhaul bus_dma(9) usage in et(4) and clean up TX/RX path.  This
  change should make et(4) work on any architectures.
   o Remove m_getl inline function and replace it with stanard mbuf
     interfaces.  Previous code tried to minimize code duplication
     but this came from incorrect use of common DMA tag.
     Driver may be still use a common RX allocation handler with
     additional structure changes but I don't see much point to do
     that it would make it hard to understand the code.
   o Remove DragonflyBSD specific constant EVL_ENCAPLEN, use
     ETHER_VLAN_ENCAP_LEN instead.
   o Add bunch of new RX status definition.  It seems controller
     supports RX checksum offloading but I was not able to make the
     feature work yet.  Currently driver checks whether recevied
     frame is good one or not.
   o Avoid a typedef ending in '_t' as style(9) says.
   o Controller has no restriction on DMA address space, so there
     is no reason to limit the DMA address to 32bit.  Descriptor
     rings,  status blocks and TX/RX buffers now use full 64bit DMA
     addressing.
   o Allocate DMA memory shared between host and controller as
     coherent.
   o Create 3 separate DMA tags to be used as TX, mini RX ring and
     stanard RX ring.  Previously it created a single DMA tag and it
     was used to all three rings.
   o et(4) does not support jumbo frame at this moment and I still
     don't quite understand how jumbo frame works on this controller
     so use two RX rings to handle small sized frame and normal sized
     frame respectively.  The mini RX ring will be used to receive
     frames that are less than or equal to 127 bytes.  The second RX
     ring is used to receive frames that are not handled by the first
     RX ring.
     If jumbo frame support is implemented, driver may have to choose
     better RX scheme by letting the second RX ring handle jumbo
     frames.  This scheme will mimic Broadcom's efficient jumbo frame
     handling feature.  However RAM buffer size(16KB) of the
     controller is too small to hold 2 jumbo frames, if 9KB
     jumbo frame is used, I'm not sure how good performance would it
     have.
   o In et_rxeof(), make sure to check whether controller received
     good frame or not.  Passing corrupted frame to upper layer is
     bad idea.
   o If driver receives a bad frame or driver fails to allocate RX
     buffer due to resource shortage condition, reuse previously
     loaded DMA map for RX buffer instead of unloading/loading RX
     buffer again.
   o et_init_tx_ring() never fails so change return type to void.
   o In watchdog handler, show TX DMA write back status of errored
     frame which could be used as a clue to debug watchdog timeout.
   o Add missing bus_dmamap_sync() in various places such that et(4)
     should work with bounce buffers(e.g. PAE).
   o TX side bus_dmamap_load_mbuf_sg(9) support.
   o RX side bus_dmamap_load_mbuf_sg(9) support.
   o Controller has no DMA alignment limit in RX buffer so use
     m_adj(9) in RX buffer allocation to make IP header align on 2
     bytes boundary.  Otherwise it would trigger unaligned access
     error in upper layer on strict alignment architectures.
     One of down side of controller is it provides limited set of RX
     buffer length like most Intel controllers.  This is not problem
     at this moment because driver does not support jumbo frame yet
     but it may require alignment fixup code to support jumbo frame
     on strict alignment architectures.
   o In et_txeof(), don't zero TX descriptors for transmitted frames.
     TX descriptors don't need write access after transmission.
     Driver sets IFF_DRV_OACTIVE when the number of available TX
     descriptors are less than or equal to ET_NSEG_SPARE.  Make sure
     to clear IFF_DRV_OACTIVE only when the number of available TX
     descriptor is greater than ET_NSEG_SPARE.

git-svn-id: svn://svn.freebsd.org/base/stable/9@229717 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f