Prev: How to show media/cable disconnected
Next: Printer Name Issue
From: Maxim S. Shatskih on 22 Jul 2006 06:26
> Since an ethernet frame is ~1500 bytes maximum, can I safely just issue
> USB reads of say, 2K, and then (assuming the device is behaving
> properly) treat each completed read request as a full frame?

This depends upon your hardware and how it indicates the received frames.

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

From: chris.aseltine on 22 Jul 2006 22:34
Doron and Eliyas,

> For reading data from an USB endpoint on a continuous basis, you should use
> the KMDF continuous reader interface -
> WdfUsbTargetPipeConfigContinuousReader. It will do lot of heavy lifting
> interms of formatting, reusing, and reposting the request for every read.

Continuous reader sounds like a great idea -- and yes, I'll need to
constantly be reading frames from the BULK IN endpoint (I was going to
at least use a continuous reader for my device's interrupt endpoint,
which sends out-of-band status indications and so on).

However, like I mentioned earlier, the existing NDISEDGE sample has a
fairly elaborate setup in place for posting reads from a buffer of
memory utilizing watermarks and so on. Was this intended to maximize
capability with existing lower-level drivers?

I'm assuming that to utilize this approach, I'll scrap most of the
existing code in NICAllocRecvResources(), and instead simply set up a
continuous reader on the BULK IN endpoint -- and inside the completion
routine for the reader, just call NICIndicateReceivedPacket() for each
completed read. (Maxim, I'm operating under the assumption that each
completed read from the device contains a full ethernet frame.)

That's a lot easier, but I'm just wondering if I've overlooked
something -- especially given how much code I won't need -- so just a
little confirmation would be great. Since I'm losing the buffering
aspect of the approach, will any performance concerns be introduced?
I'm only using full speed / 12Mbps USB, so I'm thinking no.

Thanks again.

-Chris

From: chris.aseltine on 22 Jul 2006 23:39
chris.aseltine(a)gmail.com wrote:

> I'm assuming that to utilize this approach, I'll scrap most of the
> existing code in NICAllocRecvResources(), and instead simply set up a
> continuous reader on the BULK IN endpoint -- and inside the completion
> routine for the reader, just call NICIndicateReceivedPacket() for each
> completed read. (Maxim, I'm operating under the assumption that each
> completed read from the device contains a full ethernet frame.)

By the way, looking at the code inside NICIndicateReceivedPacket -- it
looks like they temporarily raise the IRQL to DISPATCH_LEVEL if
"Adapter->HardwareDevice" is TRUE -- yet, if I'm reading the KMDF help
file correctly, the continuous reader callback is already called at
DISPATCH_LEVEL -- so despite the bit about Adapter->HardwareDevice
being true in this case, I think I could just leave the IRQL
alone...right?

Is this done because the reads are posted from a work item, which is
running at PASSIVE_LEVEL?

Also, I don't suppose I can "scrap" most of the code in
NICAllocRecvSources, as it seems NDIS wants the frames stored in some
previously configured resources through NdisAllocateBuffer/Packet().
However, it does seem like I can at least avoid the complexity of
having a queue of these resources, and perhaps just create one of each
(packet, buffer, etc.) given that I am limited by the hardware in this
instance -- would you agree?

I'm thinking the same does not apply for the "send" side of the
equation -- I'll definitely need to be able to queue "write" frame
requests that are coming from the OS, and rather than just manipulate
some locking mechanism inside the "write" completion routine, it seems
like it might be wiser just to leave in place the queuing mechanism
that already exists in the driver -- agree?

-Chris

From: Doron Holan [MS] on 23 Jul 2006 11:34
> Is this done because the reads are posted from a work item, which is
> running at PASSIVE_LEVEL?

your read completion routine from the continuous reader is called from an
IRP completion routine. irp completion routines do not have IRQL guarantees,
sothe IRQL when called could be DISPATCH_LEVEL or *lower*. From thesound of
it NDISdoes the IRQL change, so this is not something you have to deal with.

> However, it does seem like I can at least avoid the complexity of
> having a queue of these resources, and perhaps just create one of each
> (packet, buffer, etc.) given that I am limited by the hardware in this
> instance -- would you agree?
if you are mapping a resource to a completed transfer ont he BULK IN
endpoint, this won't work. Just becase you indicate a packet to NDIS, does
not mean that it will be consumed and returned to your driver immediately.
There could be many outstanding indicated packets at a time.

d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<chris.aseltine(a)gmail.com> wrote in message
news:1153625955.081662.242840(a)h48g2000cwc.googlegroups.com...
> chris.aseltine(a)gmail.com wrote:
>
>> I'm assuming that to utilize this approach, I'll scrap most of the
>> existing code in NICAllocRecvResources(), and instead simply set up a
>> continuous reader on the BULK IN endpoint -- and inside the completion
>> routine for the reader, just call NICIndicateReceivedPacket() for each
>> completed read. (Maxim, I'm operating under the assumption that each
>> completed read from the device contains a full ethernet frame.)
>
> By the way, looking at the code inside NICIndicateReceivedPacket -- it
> looks like they temporarily raise the IRQL to DISPATCH_LEVEL if
> "Adapter->HardwareDevice" is TRUE -- yet, if I'm reading the KMDF help
> file correctly, the continuous reader callback is already called at
> DISPATCH_LEVEL -- so despite the bit about Adapter->HardwareDevice
> being true in this case, I think I could just leave the IRQL
> alone...right?
>
> Is this done because the reads are posted from a work item, which is
> running at PASSIVE_LEVEL?
>
> Also, I don't suppose I can "scrap" most of the code in
> NICAllocRecvSources, as it seems NDIS wants the frames stored in some
> previously configured resources through NdisAllocateBuffer/Packet().
> However, it does seem like I can at least avoid the complexity of
> having a queue of these resources, and perhaps just create one of each
> (packet, buffer, etc.) given that I am limited by the hardware in this
> instance -- would you agree?
>
> I'm thinking the same does not apply for the "send" side of the
> equation -- I'll definitely need to be able to queue "write" frame
> requests that are coming from the OS, and rather than just manipulate
> some locking mechanism inside the "write" completion routine, it seems
> like it might be wiser just to leave in place the queuing mechanism
> that already exists in the driver -- agree?
>
> -Chris
>


From: chris.aseltine on 23 Jul 2006 23:05
Doron Holan [MS] wrote:

> > Then, say I get a sixth read completion from the bulk endpoint. Now
> > I'm out of buffers, but I need to do something with the data that I
> > just read in. What would I do in this situation?
>
> either queue the data and wait for one of your receive resources to be
> returned or allocate a new receive resource on the fly. I am pretty sure
> the point of preallocating the resources it make sure you can make fwd
> progress and that you are not allocating in the recv path on every packet.

Well, in the former case, that sounds like a reasonable solution,
although being a driver novice, I feel implementing that might take me
into blue screen territory. I'm assuming the process would be
something like: create a work item, watch for the "free receive
resource" count to increase above zero, and so on.

Then, (presumably, based on other driver work I've done) I also have to
watch for a device disconnection (or other similar events) that would
require unloading the driver, which would then in turn need to flush
all the work items that are waiting for these receive resources to be
freed up -- in WDM land I've gotten blue screened by worker threads
which were not cleaned up by DriverUnload() time (even after
synchronizing their exits with a KEVENT -- had to insert some sleep
statements..)

In the latter case, I have to wonder what the endgame is for a
simulated scenario where NDIS is not flushing any of my indicated
packets and I keep queuing up more and more receive buffers -- I could
imagine a test case in the NDIS tester that just does this, although I
have not checked. Would I need to call WdfIoTargetStop to temporarily
halt the continuous reader?

This seems like a lot of work just to use a USB continuous reader -- is
there anything inherently disadvantageous about just reusing vanilla
USB read requests, especially given that the NDISEDGE driver has the
skeleton code for doing so?

Please understand by no means am I trying to argue, since I'm sure your
experience far outweighs mine :), but I'm just trying to think through
the implications of each approach before I commit time to implementing
either one.

Thanks again.

-Chris

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: How to show media/cable disconnected
Next: Printer Name Issue