-----Original Message-----
From: Ivan Bublikov [mailto:xxxxx@yahoo.com]
Sent: Wednesday, October 08, 2003 11:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: DMA adapter object, common buffer and
mapping registers
Mark,
I understand what you mean. I’d like to use the abstraction
“as documented”, that is exactly what I’m trying to do, but
the documentation is confusing me. Just read this one more time:
“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.”
“or all” - how do you interpret that? Does it really mean
“all”, or does it mean “all that are left after reserving
some to be able to fulfill the promises made by whatever
IoAllocateAdapter calls were made so far”?
Or “map registers associated with the adapter object”. What
does “associated” mean? Does it simply mean “registers used
to map the memory accesses from the bus this bus-master
adapter resides on”, so they are associated with the adapter
in the sense that they are associated with its bus? Or does
it mean some “sub-set of registers specifically associated
with this adapter”? If, as you say, there is a “global pool
of map registers set aside for common buffers” (in abstract
sense), allocations from which do not count against the
“packed-based” guarantee, why does the documentation use
terms “associated with the adapter object”? If common buffers
do not count against “packet based” guarantee, there is no
place for such association, in the abstraction.
Ivan
“Roddy, Mark” wrote in message
> news:xxxxx@ntdev…
> >
> > 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 isters
> > >
> > >
> > > Mark,
> > >
> > > 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
> >
> >
>
>
> —
> 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