找黄大侠和各位高手解决一个性能问题

写了一个IM。
通了。能用。但性能不好。
现在是这个IM控制两个NIC。就是进行数据转发。从A发到B。B发到A。
现在使用的策略是
1。接收到PACKET。复制数据（一定要复制，因为将来这个数据会做过滤功能）。调用NDIS_WORK_ITEM.
2。NDIS开始根据NDIS_WORK_ITEM回调发送函数。

但现在传输速度不够快。：（

黄大侠给点建议吧。

各位大侠给点意见啊

不妨参考WinDump的做法，文档中对于性能问题有很详细的论述。

写了一个IM。
通了。能用。但性能不好。
现在是这个IM控制两个NIC。就是进行数据转发。从A发到B。B发到A。
现在使用的策略是
1。接收到PACKET。复制数据（一定要复制，因为将来这个数据会做过滤功能）。调用NDIS_WORK_ITEM.
2。NDIS开始根据NDIS_WORK_ITEM回调发送函数。

但现在传输速度不够快。：（

黄大侠给点建议吧。

为什么需要work_item？
直接转发有什么不妥？

还是胡大侠厉害。
一下搞到正点位置了。前天睡觉迷糊中决定放弃WORK_ITEM。直接转发。速度性能被突破。一切搞定了。

另外请教胡大侠，如果在ProtocolReceive中处理的时间过长。这个时候Miniport会不会直到Receive函数处理完毕后才指示新的数据包接收？
当时设计用WORK_ITEM也就是担心这个问题。怕处理时间过长。而让Miniport把后面的包给扔了。

另外。。。。。。。。写错了胡大侠的姓。。。嘿嘿。别生气。

前段时间错过了NDIS大会。遗憾。不过你们的报道、图片和MP3我都下了。学习了一下。收益匪浅。谢谢

还是胡大侠厉害。
一下搞到正点位置了。前天睡觉迷糊中决定放弃WORK_ITEM。直接转发。速度性能被突破。一切搞定了。

另外请教胡大侠，如果在ProtocolReceive中处理的时间过长。这个时候Miniport会不会直到Receive函数处理完毕后才指示新的数据包接收？
当时设计用WORK_ITEM也就是担心这个问题。怕处理时间过长。而让Miniport把后面的包给扔了。
 

ndis本身是异步的。所以接收函数和发送函数都是可能重如的。
所以，使用work_item不是好主意。应该精确检查代码，保证
所有代码的异步性，保证代码多次重入的安全性。

谢谢。那偶就不担心了。