接收大量(r)UDP流量时CPU负载高(Windows)

我正在研究使用大量传入数据进行进一步处理的应用程序的问题(多播传输流,具体而言).

情况如下:添加了多个组播流.每个都有自己的接收器线程,从套接字接收数据,然后将其复制到一个环形缓冲区.它不再做了.

在大约500到600 mbit,一个特定的CPU核心达到100%.实际上,在初始化流并且随着以太网流量的增加时,我可以看到它几乎线性地向该负载上升.

套接字代码使用WSA重叠API.即使我减少线程只做那个(即不复制到ringbuffer,这反过来又将主机应用程序的任何负载减少到接近零),我很容易将那个特定的核心沉入红色.同样有趣的是,即使我通过亲和设置将其限制为4个完全不同的核心,此负载也存在于该特定核心上.让我得出结论,时间花在操作系统或驱动程序级别上.

我曾尝试在复制之前立即收集n个数据报(即超过1500字节的MTU),但这只会让事情变得更糟.我还检查了我的套接字是否配置正确(非阻塞,返回值都可以).

我想知道是否有人可以告诉我一些有关此问题,或许有这个问题,或者对如何在Windows上有效处理这些流量有一些有用的见解.

(我正在使用的NIC:Intel PRO PT1000)

UPDATE

我设置了一个只有一个目标的小测试应用程序:从任意数量的多播中获取传入的UDP.我正在使用像Len建议的IO完成端口策略这样做.现在我可以轻松地从28个多播中获得1Gbit的CPU负载(毕竟现在我没有对数据包做任何事情),但是当使用更多(更小带宽)的多播(通常在这台机器上超过70)时,吞吐量变得越来越糟,工人线程似乎不平衡,大多浪费时间(等待).

NIC中断负载现在不是限制因素(之前是).

我对这种材料,多线程网络的东西很陌生.工作线程只是在IO完成端口(GetQueuedCompletionStatusEx())w/INFINITE上等待,然后当流读取完成时,我立即发出另一个并循环(如果我可以同步在同一个流上获得更多) ,我会在没有发布新IO事件的情况下接受这些事件,FILE_SKIP_COMPLETION_PORT_ON_SUCCESS).

我拥有尽可能多的工作线程,因为我有CPU内核(任何(远)超过使事情变得更糟).

不认为这保证了一个新的问题 - 但是,再次,任何帮助非常感谢!

这是我的测试应用程序的来源.(C++) - 应该是可读的:-) http://pastebin.com/xWEPPbi6