Date: Wed, 22 Aug 2001 14:53:51 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: gibbs@scsiguy.com (Justin T. Gibbs) Cc: mjacob@feral.com, hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Where to put new bus_dmamap_load_mbuf() code Message-ID: <20010822215351.3090537B40B@hub.freebsd.org> In-Reply-To: <200108222115.f7MLFiY16846@aslan.scsiguy.com> from "Justin T. Gibbs" at "Aug 22, 2001 03:15:44 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> The fact that the data is less than a page in size matters little
> to the bus dma concept. In other words, how is this packet presented
> to the hardware? Does it care that all of the component pieces are
> < PAGE_SIZE in length? Probably not. It just wants the list of
> address/length pairs that compose that packet and there is no reason
> that each chunk needs to have it own, and potentially expensive, dmamap.
Maybe, but bus_dmamap_load() only lets you map one buffer at a time.
I want to map a bunch of little buffers, and the API doesn't let me
do that. And I don't want to change the API, because that would mean
modifying busdma_machdep.c on each platform, which is a hell that I
would rather avoid.
> >Why can't I just call bus_dmamap_load() multiple times, once for
> >each mbuf in the mbuf list?
>
> Due to the cost of the dmamaps, the cost of which is platform and
> bus-dma implementation dependent - e.g. could be a 1-1 mapping to
> a hardware resource. Consider the case of having a full TX and RX
> ring in your driver. Instead of #TX*#RX dmamaps, you will now have
> three or more times that number.
>
> There is also the issue of coalessing the discontiguous chunks if
> there are too many chunks for your driver to handle. Bus dma is
> supposed to handle that for you (the x86 implementation doesn't
> yet, but it should) but it can't if it doesn't understand the segment
> limit per transaction. You've hidden that from bus dma by using a
> map per segment.
Ok, a slightly different question: what happens if I call
bus_dmamap_load() more than once with different buffers but with
the same dmamap?
> >(Note: for the record, an mbuf list usually contains one packet
> >fragmented across multiple mbufs. An mbuf chain contains several
> >mbuf lists, linked together via the m_nextpkt pointer in the
> >header of the first mbuf in each list. By the time we get to
> >the device driver, we always have mbuf lists only.)
>
> Okay, so I haven't written a network driver yet, but you got the idea,
> right? 8-)
Just don't get 3c509 and 3c905 misxed up and we'll be fine. :)
> >- Added routines to allocate a chunk of maps in a singly linked list,
> > from which the other routines can grab them as needed.
>
> Are these hung off the dma tag or something? dmamaps may hold settings
> that are peculuar to the device that allocated them, so they cannot
> be shared with other clients of bus_dmamap_load_mbuf.
It's a separate list. The driver is reponsible for allocating the
head of the list, then it hands it to bus_dmamap_list_alloc() along
with the required dma tag. bus_dmamap_list_alloc() then calls
bus_dmapap_create() to populate the list. The driver doesn't have
to manipulate the list itself, until time comes to destroy it.
-Bill
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu
wpaul@windriver.com | Wind River Systems
=============================================================================
"I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos
=============================================================================
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010822215351.3090537B40B>