You have more experience than I do in this area, but I am going to reply anyway in the belief that I can contribute some useful information to the discussion. F

You have more experience than I do in this area, but I am going to reply anyway in the belief that I can contribute some useful information to the discussion. First, there is a discussion of this here: https://www.quora.com/How-is-FreeBSDs-network-stack-superior-to-that-of-Linux https://www.quora.com/How-is-FreeBSDs-network-stack-superior... The main remark seems to be: > The predominant difference is that the FreeBSD network stack was much more carefully designed. The Linux stack was less careful and thus is much more haphazard. Also, more work has been put into optimizing the FreeBSD stack. It is not my area of expertise, but the Linux skbuf seems to fit the description of haphazard while the FreeBSD mbuf seems to fit the description of more carefully designed. The same could be said about epoll versus kqueue. The remark about more work in optimizing the FreeBSD stack also seems to be true. While I cannot speak for everything in FreeBSD's network stack, I do know that FreeBSD's netmap far exceeded anything Linux could do at the time and while it is available on Linux, I never hear of it being used anywhere but on FreeBSD: http://info.iet.unipi.it/~luigi/netmap/ http://info.iet.unipi.it/~luigi/netmap/ Development of FreeBSD's network stack had plenty of innovative things in development at the time Facebook's post was made: https://wiki.freebsd.org/201405DevSummit/NetworkStack https://wiki.freebsd.org/201405DevSummit/NetworkStack That included additional contributions from a major network equipment vendor that had made many contributions throughout the years. If I checked the commit history, I imagine I would find performance work done by said vendor. From what I can tell, FreeBSD's network stack is improving regardless of whether the rest of us hear about it. Lastly, there have been multiple things discovered to be wrong in the Linux network stack since that facebook job listing. Two prominent ones that I recall offhand are: https://blog.cloudflare.com/the-story-of-one-latency-spike/ https://blog.cloudflare.com/the-story-of-one-latency-spike/ https://bitsup.blogspot.com.au/2015/09/thanks-google-tcp-team-for-open-source.html https://bitsup.blogspot.com.au/2015/09/thanks-google-tcp-tea... They both could fall into the category of stability problems to which facebook had alluded. The second one more so though: > The end result is that applications that oscillate between transmitting lots of data and then laying quiescent for a bit before returning to high rates of sending will transmit way too fast when returning to the sending state. This consequence of this is self induced packet loss along with retransmissions, wasted bandwidth, out of order packet delivery, and application level stalls.