Re: Direct Copying To Share Memory In NDIS ProtocolReceive


"Le Chaud Lapin" <jaibuduvin@xxxxxxxxx> wrote in message news:1172798341.812254.5470@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mar 1, 1:17 pm, "Thomas F. Divine" <tdivine@NOpcausaSPAM> wrote:
Best approach is still to use standard DeviceIocontrol or Read instead of
shared memory. The effect you seek is achievable using this method.

Use Read with DO_DIRECT_IO. Application allocates large structured buffer
with room for seveveral (many) packets. Driver uses
MmGetSystemAddressForMdlSafe to map buffer to kernel memory. Then pends the
read and stashes buffer and IRP internally. Driver fills buffer with
multiple packets and eventually completes the read IRP.

This minimizes user-kernel transitions (i.e, number of I/O calls) - which is
a performance killer. Also, there is no memory copy between user-mode buffer
and kernel-mode buffer (because DO_DIRECT_IO was used). In addition, driver
is safely informed (via Cleanup/Close callbacks) when application leaves the
building.

Improvements on this include 1.) having multiple concurrent Reads in
progress so driver already has another Read buffer queued when current one
becomes filled and 2.) having a timer that will complete a Read eventually
even if buffer is not filled.

This, or variations on this, should work for you withoug having to have
shared memory and events that are not part of the standard I/O scheme.

Hi Thomas,

I thought this was essentially the same thing I was proposing. The
difference seems to be that, in your method, the large buffer is
specified in user-space before ReadFile is invoked. In the scheme I
was proposing, the large buffer is always available, in the shared
section consisting of frame slots, and the driver has to figure out
which of the frame slots in the section are free while inside
ProtocolReceive. Naturally, in my scheme, I would lock the shared
section from birth to death and exercise caution in cleanup.

A critical design criteria is that all received packets _must_
ultimately be written to the shared section, so ideally, I would like
to avoid a secondary copy, and write straight to the sections. But
there are 3 applications and N drivers that share the section, and
they compete for slots using global semaphore (by design), so if I pre-
allocated a chunk of slots in ReadFile, I could end up being overly
greedy, taking away valuable slots from the other two processes or
drivers that might need them. There would be waste if ReadFile
overallocates. This is why I was thinking about my original plan.
The driver can fill as many frame slots in the shared section as
possible, never consuming more slots than it actually needs, and when
the user-mode code cycles around to ReadFile, waiting for it will be a
chunk of frame slots ready to be read, but not by pulling up the
packets, but by pulling up the the array of indexes of slots that were
filled by ProtocolReceive.

-Le Chaud Lapin-

Surely with enough work and debugging you can get your scheme to work. Do sit back and seriously consider my personal motto: "Keep it simple, stupid!".

Good luck,

Thomas F. Divine


.

Relevant Pages

  • Re: Direct Copying To Share Memory In NDIS ProtocolReceive
    ... Application allocates large structured buffer with room for seveveral packets. ... Driver fills buffer with multiple packets and eventually completes the read IRP. ... This, or variations on this, should work for you withoug having to have shared memory and events that are not part of the standard I/O scheme. ... I am wondering if I can obviate much of the NDIS packet allocation by ...
    (microsoft.public.development.device.drivers)
  • Re: Difference between synchronous and asynchronous operation/calls (NDISPROT)
    ... The main problem with synchronous operation/calls seems to be the lack of buffers for the driver to store data into. ... Each "read call" supplies the driver with a buffer and optionally a completion routine so that the driver can inform the application when the requested operation is/was done. ... However it seems the current windows/driver design does some copies as well? ...
    (microsoft.public.development.device.drivers)
  • Re: NDIS IM driver usermode app communication
    ... >> then have the usermode app read from it, but that approach would be ugly. ... > the driver fill the buffer with multiple packets. ...
    (microsoft.public.development.device.drivers)
  • Re: Degradation of TCP connection
    ... Gigabit ethernet. ... D card's data buffer can only hold about 64K samples worth of data ... link you posted is for an older version of VxWorks that used a BSD- ... but a bug in the ethernet driver. ...
    (comp.os.vxworks)
  • Re: PCI bus-master and large contiguous memory buffers
    ... As soon as device reaches the end of the buffer ... Sure, I am developing both PCI adapter and device driver, so, it is ... not afford reinitializing DMA on my device after every transfer. ... x86 CPU memory management structures I never tried to dig into Windows ...
    (microsoft.public.development.device.drivers)