Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Jan 2009 09:52:34 -0700
From:      Scott Long <scottl@samsco.org>
To:        Sepherosa Ziehau <sepherosa@gmail.com>
Cc:        barney_cordoba@yahoo.com, current@freebsd.org
Subject:   Re: DMA bounce buffers
Message-ID:  <497DEA52.3040004@samsco.org>
In-Reply-To: <ea7b9c170901260557p539221eena791b4cb2a73f1b5@mail.gmail.com>
References:  <497758.90319.qm@web63903.mail.re1.yahoo.com> <ea7b9c170901260557p539221eena791b4cb2a73f1b5@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Sepherosa Ziehau wrote:
> On Mon, Jan 26, 2009 at 9:05 PM, Barney Cordoba
> <barney_cordoba@yahoo.com> wrote:
>> I have a problem with the ixgbe driver, where bus_dmamap_load_mbuf_sg() is
>> failing. The underlying failure is reserve_bounce_pages(). It seems that
>> there aren't any bounce pages allocated. What could be the cause of this? Is there some tunable?
> 
> I don't think the hardware supported ixgbe(4) will need bounce pages
> on RX/TX buffers (according to data sheet, the hardware supports full
> 64bits address space accessing and no alignment constraints on RX/TX
> buffer start address).  However, the driver's buffer busdma is kinda
> misconfigured: in ixgbe_allocate_{transmit,receive}_buffers(), the
> buffers' alignment is set to PAGE_SIZE (?!), this means that almost
> all TX/RX operation will require bouncing.  The best case is poor
> performance due to additional and unnecessary memory copy in
> bus_dmamap_sync(); the worst case is completely unfunction NIC due to
> RX ring could not be filled during ifnet.if_init().
> 

Yes, no high-speed NIC should be using bounce buffers.  I haven't looked 
at the ixgbe data sheets, but I'd be highly surprised if this hardware
actually needed buffer alignment like that.  If it does, then the better
thing to do is to either use 4k mbuf clusters (and make sure that the 
system doesn't try to treat them as jumbo frames), or have the rx ring
allocator throw away and reallocate any clusters that aren't already on
4k boundaries (normal clusters are 2k, so it'll have a nominal 50% 
chance of getting what it needs).  Neither of these solutions is ideal,
though.

Scott



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?497DEA52.3040004>