Prev: driver installation failed in xp with 7600.16385.0 build environme
Next: kernel base address
From: mirage2k2 on 4 Mar 2010 21:08
I need to decompress a compressed inbound packet in my receive packet handler
.... it runs at DISPATCH_LEVEL. The packet cannot be passed up the network
stack until it has been decompressed. Deferring the handling of the packet
to a system thread that runs at PASSIVE_LEVEL will have too much of an impact
on the packet flow.

"m" wrote:

> None at all - but the better question is why you want to scan a pattern
> buffer at DISPATCH! If you find something bad, then, since the upper level
> has already received some of it, your response, in general, has no different
> efficacy than if you were scanning on a passive thread / work item, but the
> scanning has much less impact on overall system perf.
>
> "mirage2k2" <mirage2k2(a)discussions.microsoft.com> wrote in message
> news:DA1CC7E1-1C50-4189-9326-053F9418CC84(a)microsoft.com...
> > Thanks everybody for all your help. So it seems that the best option for
> > me
> > is to use paged memory and then use mm functions to page it in and lock it
> > down so that it can never be paged out. Does anyone see a reason why this
> > will not work? Also, is it definately ok to access paged memory at
> > DISPATCH_LEVEL ... provided that it is paged in and locked down?
> >
> > Mirage2k2.
> >
> > "mirage2k2" wrote:
> >
> >> The documentation on MmAllocateContiguousMemory says that it attempts to
> >> allocate memory from the non-paged pool, and if this fails then "it
> >> attempts
> >> to perform the allocation from available unused pages".
> >>
> >> Firstly, what on earth does that mean? Secondly, will the memory "from
> >> available unused pages" still be non-paged? I will be accessing it at
> >> DISPATCH_LEVEL so I need to be certain.
> >>
> >> My guess is that the memory available in "unused pages" is somehow mapped
> >> into the non-paged pool ... thus increasing the size of the pool.
> >>
> >>
> >> My next question is about the size of the non-paged pool. I've read a
> >> few
> >> articles that suggest that there is a limit of 250MB, irrespective of
> >> total
> >> RAM. Does anyone know if there is a way of changing the configuration
> >> of
> >> the system to make this value higher, i.e. some weird registry setting or
> >> some system API call.
> >>
> >> Basically I need to allocate between 32MB - 64MB of non-paged memory, at
> >> any
> >> given time, and I need it to work. Allocating the memory in DriverEntry
> >> at
> >> startup is probably my best shot but there will be times when I don't
> >> need to
> >> allocate anything at all ... I don't want to allocate 32MB and then never
> >> use
> >> it ... or hog it until I do need it.
> >>
> >> Does anyone have any ideas?
> >> Thanks
> >> Mirage2k
> >>
> .
>
From: Maxim S. Shatskih on 5 Mar 2010 03:47
> will not work? Also, is it definately ok to access paged memory at
> DISPATCH_LEVEL ... provided that it is paged in and locked down?

Yes, but you cannot lock at DISPATCH_LEVEL.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: Maxim S. Shatskih on 5 Mar 2010 03:48
>I need to decompress a compressed inbound packet in my receive packet handler

Then why do you need these huge megabytes?

Allocate the space enough for, say, 100 packets - i.e. 150KB.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: mirage2k2 on 5 Mar 2010 07:16
the huge megabytes are for packet history, the larger the history the better
the compression. Anyway, thanks for all your help. I now do this and it
works ok ...

PMDL mdl;
UCHAR *testPagedMem = (
(UCHAR *)ExAllocatePoolWithTag(PagedPool, MEM_SIZE, 'aaa1')
);
if (testPagedMem == 0)
{
return;
}

mdl = IoAllocateMdl(testPagedMem, MEM_SIZE, FALSE, FALSE, 0);
if (mdl == 0)
{
return;
}

MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);

Mirage2k

"Maxim S. Shatskih" wrote:

> >I need to decompress a compressed inbound packet in my receive packet handler
>
> Then why do you need these huge megabytes?
>
> Allocate the space enough for, say, 100 packets - i.e. 150KB.
>
> --
> Maxim S. Shatskih
> Windows DDK MVP
> maxim(a)storagecraft.com
> http://www.storagecraft.com
>
> .
>
From: Aram Hăvărneanu on 5 Mar 2010 08:07

"mirage2k2" <mirage2k2(a)discussions.microsoft.com> wrote in message
news:22D262D5-0AFB-4DE3-AD81-729D7B9040E4(a)microsoft.com...
> the huge megabytes are for packet history, the larger the history the
> better
> the compression.

True, but hundreds of megabytes?!? Not to mention increasing compression
cost (CPU time) with packet history...

I estimate keeping track of more then 1,000 is useless.

--
Aram Hăvărneanu

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: driver installation failed in xp with 7600.16385.0 build environme
Next: kernel base address