I legitimately don't see why you would.

This isn't one of these "Windows sucks!" posts. Windows is a very good endpoint for many services (DNS, DHCP, AD, IIS/ASP.net, VPNs, etc) and of course an extremely popular client.

But that being as it may, packet storms should never be allowed to hit endpoints, that the entire purpose of packet filtering. So you'll want to be taking them out on front-line appliances, and appliances based on the Windows NT kernel simply don't exist.

So this is why CloudFlare cares about this, they're utilising Linux on an appliance in front of their endpoints to try and drop as many "bad" packets as they can detect. Both Linux and various BSD variants are used commonly on networking equipment, so trying to optimise them seems to make a lot of sense.

Windows on the other hand? If you're trying to do packet filtering on the endpoint itself then you're fighting a losing battle. For example, they're low-level hooking network traffic, and while that works wonderfully for filtering, it is a terrible idea if the machine is used for other things as it can disrupt normal legitimate machine traffic.

My use case is different, It is more about packet capturing on the endpoint than packet filtering. In my use case the filtering refers to filtering uninterested data.

Also, this is oriented to internal network endpoints not visible from Internet, so I don't expect to receive massive network-intensive attacks.

So long you create a filter that limits the data you're capturing you should be fine. This is assuming you can write a filter that gets your captured traffic down to something manageable. It's possible that most endpoint devices will not have spare capacity to add 10G capturing to their workload.

Check out the Myrcom Sniffer 10G, it supports Windows, Linux & FreeBSD https://www.myricom.com/software/sniffer10g.html

It is completely OS-bypass, and should be good to handle full line rate (14.8Mpps per port).

For my Masters' work, I needed high speed tx/rx on Windows and looked into the same things you did. I can't find the statistics for the tests I ran, but WinPcap's speeds weren't much better than Winsock's, which was fairly poor. The solution I used was an NDIS kernel filter and protocol driver which pushed the packets into user-space memory. Luigi Rizzo has recently added a Windows port of netmap to his repository, so you might want to look into that: https://github.com/luigirizzo/netmap

Did you look into registered I/O?

https://technet.microsoft.com/en-us/library/Hh997032.aspx

Thanks for the netmap reference, we will take a look.

In our tests WinPcap was faster than an NDIS driver, so it will be interesting to compare.

I faced this. I wrote a network search engine and used F#. For ease I deployed on Windows. Winpcap is fine, but you don't have a lot of space to easily improve. Looking at the features the Intel NICs had and how easy it was to use them on Linux... Why would I ever want to try to optimize it on Windows?

That said I think the Wireshark guys (linked from the Wireshark site anyways) might have some answers. I know for WiFi capture they had fully functional Windows devices.

I answer to UnoriginalGuy about my use case.