Can threading provide any performance gains for NDIS drivers

Can threading provide any performance gains for NDIS drivers

I work in a small team (4) in CO developing an NDISdriver providing a wireless abgimplementation of a Soft Access Point on the Grantsdale desktop. Its part of the Caswell product. I am interested to know what we might be able to take advantage of within the driver to leverage mutiproc/hyperthread platforms, and multi-threading in general. Our driver isalready 'deserialized', butmaybe there is something we can do to make our data path run faster. We have, for instance, RC4 packet decrypt within the driver, and we shall soon be importinginto the actual drivercode,AES decrypt. Does anyone know if there may be a way to 'offload' decryption to a dedicated thread, within the driver. Idon't think that there's any way to do it, or that it would help overall wireless network throughput or efficiency, but I would be glad to hear differently.

Thanks

Dave

2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Dave -

I'm not sure about performance increases (you'll just have to try it and see), but it should be pretty easy to set up a dedicated decryption thread. The first question to ask yourself, though, is "Does the processing allow for two threads(one to decrypt and one to continue with whatever else is going on) to be executing concurrently?" If not, you would just be dividing up a serial process between threads with no benefit and some additional overhead that would adversely affect performance.

How does the decryption process start now? Is there some interrupt that identifies when encrypted data is arriving and the process switches over to the decryption functions? If so, you should be able to spawn a thread early in the execution and, whenever the decrypt signal is seen, wake up the decrypt thread to start processing while the main thread continues with whatever it was doing. Once the work is done, the decryption thread goes back to sleep waiting for the next input. If the decrypted results are needed by the main thread, it can pause execution waiting for a signal from the decrypting thread that the data is available. Otherwise, the main thread would be free to continue processing in parallel with the decrypting thread.

You'll want to make sure that the overhead of waking and putting a thread to sleep will be worthwhile. If the number of blocks in need of decryption is relatively small, you may find that the overhead takes more time than the decryption. This will be something that you can investigate and tune after implementing the threaded algorithm.

-- clay

Leave a Comment

Please sign in to add a comment. Not a member? Join today