Ivan,
What I said was that commonbBuffers, as far as I know, do not consume the
*abstraction* that NT refers to as map registers. How this is implemented is
a per platform detail. The point is that you do not have to perform your
calculation that ‘my common buffer is N pages so it must consume (N * m) map
registers’. If indeed common buffers are implemented using real hardware map
registers, then it is the OS/HAL that has to deal with how this is done, and
they have to do so in a way that at least appears to be independent of
packet dma map register allocations. For example the platform might
pre-allocate hardware map registers for common buffers. You are trying to
worry about how the OS might provide the abstraction, rather than simply to
use the abstraction as documented. This approach defeats the point of having
these platform independent abstractions. On the other hand I could be wrong,
and the documentation could be incorrect (by omission.) It wouldn’t be the
first time that the Current Wisdom is proven false.
=====================
Mark Roddy
-----Original Message-----
From: Ivan Bublikov [mailto:xxxxx@yahoo.com]
Sent: Tuesday, October 07, 2003 11:43 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: DMA adapter object, common buffer and
mapping reg istersMark,
I’m used to viewing the “map register” as an equivalent of a
page table entry, which is used by a peripheral device rather
than a CPU. I can imagine a 64-bit machine that has more than
4Gb of physical memory and also has map registers implemented
in hardware, to provide a 32-bit virtual address space for
32-bit bus-master devices, so that Windows doesn’t need to
implement map registers as intermediate buffers in the low
4Gb of physical memory, and allocate common buffers there,
too, for such devices, as would be the case when the devices
are addressing the physical memory directly. In this machine,
map registers can be a limited resource, and common buffers
can consume map registers. I don’t know if such a machine
exists or even makes sense to produce, but Microsoft’s DMA
architecture appears to be capable of handling it.“Roddy, Mark” wrote in message
> news:xxxxx@ntdev…
> >
> > Common buffers, as far as I know, do not consume map
> registers. They
> > are
> an
> > abstraction for physically contiguous system memory space
> that meets
> > the alignment, address, and other limitations of the target
> device and
> > its IO bus.
> >
> >
> > =====================
> > Mark Roddy
> >
> >
> > > -----Original Message-----
> > > From: Ivan Bublikov [mailto:xxxxx@yahoo.com]
> > > Sent: Monday, October 06, 2003 7:55 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: [ntdev] Re: DMA adapter object, common buffer
> and mapping
> > > registers
> > >
> > >
> > > Let me re-phrase my question. Let’s suppose I call
> IoGetDmaAdapter
> > > and it gives me 4 map registers. Then I call
> AllocateCommonBuffer on
> > > this adapter to allocate 2 pages. I suppose, this will “tie up” 2
> > > map registers. Does that mean that I now have only 2 map
> registers
> > > left for my future “packet-based” DMA transfers using this same
> > > adapter?
> > >
> > >
> > > “Maxim S. Shatskih” wrote in message
> > > news:xxxxx@ntdev…
> > > >
> > > > > Setting up common-buffer areas economically, such as
> > > using PAGE_SIZE
> > > chunks
> > > > > or a single allocation, leaves more map registers
> available for
> > > packet-based
> > > >
> > > > This is because common buffer allocation can be rounded up
> > > to a page.
> > > >
> > > > Maxim Shatskih, Windows DDK MVP
> > > > StorageCraft Corporation
> > > > xxxxx@storagecraft.com
> > > > http://www.storagecraft.com
> > > >
> > > >
> > > >
> > >
> > >
> > > > Hi All,
> > >
> > > >
> > >
> > > > I’m pretty confused by the DDK documentation on
> > > relationship between a
> > >
> > > > common buffer associated with an adapter object and the
> > > number of map
> > >
> > > > registers available for “packet-based” DMA transfers using the
> > > > same
> > > adapter
> > >
> > > > object, when the mapping registers are temporary
> allocated for the
> > > duration
> > >
> > > > of transfers. I’m using bus-master DMA. When I create
> an adapter
> > > > object,
> > >
> > > > initially Microsoft seems to promise me that the number of
> > > > available
> > > mapping
> > >
> > > > registers for my further “packet-based” DMA transfers
> is what the
> > > > adapter
> > >
> > > > creation function returns. Then, I read the following:
> > >
> > > >
> > >
> > > > ---------------------------------------
> > >
> > > > Using Common-Buffer Bus-Master DMA
> > >
> > > > Use common-buffer DMA economically. Setting up a common
> > > buffer can tie
> > > > up
> > >
> > > > some (or all, depending on the size of the requested buffer) of
> > > > the map
> > >
> > > > registers associated with the adapter object that represents the
> > > bus-master
> > >
> > > > adapter.
> > >
> > > >
> > >
> > > > Setting up common-buffer areas economically, such as using
> > > > PAGE_SIZE
> > > chunks
> > >
> > > > or a single allocation, leaves more map registers available for
> > > packet-based
> > >
> > > > DMA operations. It also leaves more system memory free
> for other
> > > > purposes,
> > >
> > > > thus yielding better overall driver and system performance.
> > >
> > > >
> > >
> > > > ---------------------------------------
> > >
> > > >
> > >
> > > > What is this supposed to mean? Does it mean that I should
> > > subtract the
> > >
> > > > number of mapping registers required by the common buffer I
> > > allocated,
> > > from
> > >
> > > > the amount I can use for my “packet-based” transfers? Why
> > > does it say
> > > > “can
> > >
> > > > tie up” rather than “will tie up”?
> > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com