multiple MDL's referring to the same memory...

NTDEV
21

> The only ‘resource’ you have that is shared between packets and thus
needs

to be reference counted is the ‘page’ object in your ring buffer.

For those, you have (apparently) a fixed number of 256. I would just
allocate a slab of 256 simple structures that contain the control
fields
you need (refCnt, PMDL, etc.)

Not quite. The ring can hold 256 pages, but if I have given all the
pages to NDIS (via Indicate) and haven’t received them back (via
ReturnPacket) I will need more pages to put onto the ring to prevent
starvation under high load.

You do not need to control ‘sharing’ of the partial MDLs because they
are
only created and ‘owned’ by a single packet.

Yes. That was an oversight.

James

22

I guess I was only trying to say that the relative overhead of the control
structure was modest in comparison.

Oddly enough, after saying one should eschew extending an MDL with private
data beyond the MDL size, I find myself debugging through an interop issue
tonight with NDIS6 where the NDIS5 to NDIS6 translation layer does exactly
that! NDIS itself allocates memory in which the beginning of the memory
block is an MDL and beyond the MDL is the data described by the MDL (in one
pool allocation). I guess your idea is perfectly reasonable! MSFT is not
worried about Verifier calling fowl and perhaps then neither should you be.
Of course you need to know how large the allocation is (a page in your case
I guess) so that you can size the memory for the MDL correctly but anything
beyond that is yours to stuff context into as you wish. Gosh, I should
just not be so conservative I guess…

Cheers,
-Dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, January 23, 2009 6:30 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] multiple MDL’s referring to the same memory…

The only ‘resource’ you have that is shared between packets and thus
needs
to be reference counted is the ‘page’ object in your ring buffer.

For those, you have (apparently) a fixed number of 256. I would just
allocate a slab of 256 simple structures that contain the control
fields
you need (refCnt, PMDL, etc.)

Not quite. The ring can hold 256 pages, but if I have given all the
pages to NDIS (via Indicate) and haven’t received them back (via
ReturnPacket) I will need more pages to put onto the ring to prevent
starvation under high load.

You do not need to control ‘sharing’ of the partial MDLs because they
are
only created and ‘owned’ by a single packet.

Yes. That was an oversight.

James

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

23

>

I guess I was only trying to say that the relative overhead of the
control
structure was modest in comparison.

Oddly enough, after saying one should eschew extending an MDL with
private
data beyond the MDL size, I find myself debugging through an interop
issue
tonight with NDIS6 where the NDIS5 to NDIS6 translation layer does
exactly
that! NDIS itself allocates memory in which the beginning of the
memory
block is an MDL and beyond the MDL is the data described by the MDL
(in
one
pool allocation). I guess your idea is perfectly reasonable! MSFT is
not
worried about Verifier calling fowl and perhaps then neither should
you
be.
Of course you need to know how large the allocation is (a page in your
case
I guess) so that you can size the memory for the MDL correctly but
anything
beyond that is yours to stuff context into as you wish. Gosh, I
should
just not be so conservative I guess…

I’m sure I saw it done elsewhere too. Determining the size of an MDL is
a solved problem anyway.

I’m actually tinkering with some pretty crazy stuff at the moment…
I’ve discovered DMA_ADAPTER, and created one for my bus. At the moment I
am organising it so that the ‘logical address’ (physical address from
the bus’s point of view) is actually a grant ref. Probably makes things
easier for my NDIS adapter when I get back to that, but it makes things
a heap easier for my SCSIPORT.

I’m also doing something which is probably illegal, which is to give the
scsiport the virtual address for non-read/write calls, which reduces my
scsiport complexity yet again. My scsiport needs to inspect the buffers
of non-read/write requests, but needs the physical address of read/write
requests.

Another thing I’m doing is actually reallocating the buffer in my
DMA_ADAPTER if it isn’t aligned to a sector boundary.

I’ll see how it turns out…

James