Re: Difference between synchronous and asynchronous operation/calls (NDISPROT)


"Skybuck Flying" <spam@xxxxxxxxxxx> wrote in message news:447262eb$0$754$5fc3050@xxxxxxxxxxxxxxxxxxxxxxxxxxx
Hello,

I think I understand a little bit the differences between these two modes of operation and I would like to learn/know some more about possible problems or solutions.

The main problem with synchronous operation/calls seems to be the lack of buffers for the driver to store data into. (So far I have only examined/thought about how receiving would work in both modes)

In synchronous mode it seems the driver uses it's own buffers and it only has a few of those. If the application does not call ReadFile fast enough the driver has no choice but to through away some buffers to recycle them to catch new frames/data on the wire. So the application starts losing this information.

In asynchronous mode it seems the application supplies the driver some buffers up front... for example the application tells the driver to perform multiple read operations. 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 (the read/receive/send whatever) is/was done.

However there seems to be more to it than that. Since somebody else posted a message about decreased performance and somebody else recommend issueing multiple read request... for example 32 "outstanding" read requests... to keep the driver busy etc. Why is this exactly ?

Why would the following two simple designs give slower performance ?

1. First slow design:

Driver uses it's own single buffer and receives data into the buffer. Then informs the user/application about this via a callback and requests a buffer from the user. Then the driver copies the received data into the user's buffer.

This would almost be the same as an i/o completion routine. Maybe it's almost exactly the same. The only difference is the user only supplies the buffer when the driver requests it and not vica versa.

The copy is ofcourse bad because copieing costs cpu time. However it seems the current windows/driver design does some copies as well ? I am not to sure about that.

In the time involved in copying one buffer to user-space hundreds of other packets may be received. What to do with those?

2. Second slow design:

User supplies the buffer up front and the driver receives the data into the buffer and informs the user when it received the data via the callback. The user should supply a new buffer immediatly and then the user can process the older buffer. But ofcourse this would be a little bad... because the processing could take to long. Anyway This would prevent a copy whatever. I think this was the second design I my mind maybe I forgot what the second design was lol. This was probably it though.


Actually, same answer as 1.).

Anyway the main difference between synchronous and asynchronous operation seems to be in the buffer handlig. With asynchronous operation the user is in control of the buffers mostly. The driver still has some internal buffers but if everything goes well the driver should only need one or two internal buffers and immediatly issue i/o completion callbacks etc. However NDISPROT seems limited to only 4 internal buffers ? That seems a little bit low and worriesome.

Anyway in reality there seems to be more to it than that.

I for example do not understand what I takes to transfer a buffer from "kernel mode" to "user mode". Maybe this is simply done with a special function. But "user mode" could also have it's own thread/process and the driver could also have it's own thread/process.

So how does the driver transfer the buffer between threads/processes ?

When the buffer is initially seen at the drivers read handler is is given (or obtains) a pointer to the buffer that is valid in kernel address space. While in the kernel the driver can use this pointer as an ordinary pointer.


Which takes me to my next question:

What could prevent a driver from completing a request.... so what could prevent a driver from calling the i/o completion routine ?

There is nothing to prevent this from being done...

EXCEPT that the driver is not designed to behave this way. You can revise it to suit yourself, if you desire.

I would say from experiance that the time wasted in making unnecessary calls to the driver (i.e., calls that fetch nothing) are a big waste of resources. You REALLY wan a design that minimizes the number of calls that your application makes to the driver.

You could read about the PCAUSA Rawether for Windows product at http://www.rawether.net. This is not a shameless plug for the product, because it is clear that you want to roll your own and just want free advice. However, the Rawether documentation may give you some insight into approaches that may work for you.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.rawether.net


Which could explain why the driver needs more buffers because for some reason it can't complete it. So it has to wait and meanwhile needs more buffers to keep receiving new data ?!?

Also doesn't this mean the driver needs a while loop... to quickly perform multiple completion callbacks because it couldn't do it previously... to keep up. This while loop would cause the driver to take a little sprint and catch up if you know what I mean.

Any answers could help me make understand a little bit better how many buffers a driver needs...

Bye,
Skybuck.


.

Relevant Pages

  • Difference between synchronous and asynchronous operation/calls (NDISPROT)
    ... In synchronous mode it seems the driver uses it's own buffers and it only ... First slow design: ... Driver uses it's own single buffer and receives data into the buffer. ... This would almost be the same as an i/o completion routine. ...
    (microsoft.public.development.device.drivers)
  • Re: IRP_MJ_READ is not called in a FileSystem MiniFilter driver
    ... you should never do this direct copy, a stack location contains information for both your driver and the driver above (like its completion routine). ... Look at how IoCopyCurrentIrpStackLocationToNext is implemented if you need to copy an io stack location from one irp to another irp. ... Create ReadDone function where you can manipulate you buffer data in orgMdl ...
    (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)
  • 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)