4 ms·

>With this scale of attack the Linux kernel is not enough for us. We must work around it...we added a partial kernel bypass feature to Netmap: that's described

>With this scale of attack the Linux kernel is not enough for us. We must work around it...we added a partial kernel bypass feature to Netmap: that's described in this blog post. With this technique we can offload our anti-DDoS iptables to a very fast userspace process. What do they mean by "very fast userspace process"? If you're doing the same thing the kernel would be doing, the userspace process should be strictly slower due to context switches. What costs are they saving on here?

majke 10y ago
The "very fast userspace process" has direct access to hardware NIC RX queue and is doing busy polling. It uses 100% CPU all the time. The process is faster then kernel because: - it does less only since it implements only some subset of iptables - is single threaded, no locks - doesn't implement TCP - it's small, no iTLB misses - the working size set is small, we only deal with couple of packets at a time - no memory allocations on the hot path (no skb) - it is doing busy polling, saving the Xus needed for an interrupt context switch
- catern 10y ago
  It seems like the main thing making that process fast is the fact that it's doing polling. But Linux does polling too, when there are enough packets coming in. Likewise, if you really are dropping packets very early in the networking stack, you wouldn't reach the TCP layer and would have a small working set in the kernel too. So, why not just implement this very fast userspace process as a kernel patch? That seems much easier...
zeroxfe 10y ago
> If you're doing the same thing the kernel would be doing, the userspace process should be strictly slower due to context switches. Actually, you would cut down on context switches as you ship packets between kernel and user-space. This allows you to do all kinds of intelligent filtering and other header processing that can vastly improve latency in gateway systems (proxies, routers, VM hosts, etc.)
dgemm 10y ago
Saving an interrupt per packet. It's far fewer context switches to process packets in a busy loop.

majke 10y ago

The "very fast userspace process" has direct access to hardware NIC RX queue and is doing busy polling. It uses 100% CPU all the time. The process is faster then kernel because: - it does less only since it implements only some subset of iptables - is single threaded, no locks - doesn't implement TCP - it's small, no iTLB misses - the working size set is small, we only deal with couple of packets at a time - no memory allocations on the hot path (no skb) - it is doing busy polling, saving the Xus needed for an interrupt context switch

catern 10y ago
It seems like the main thing making that process fast is the fact that it's doing polling. But Linux does polling too, when there are enough packets coming in. Likewise, if you really are dropping packets very early in the networking stack, you wouldn't reach the TCP layer and would have a small working set in the kernel too. So, why not just implement this very fast userspace process as a kernel patch? That seems much easier...

zeroxfe 10y ago

> If you're doing the same thing the kernel would be doing, the userspace process should be strictly slower due to context switches. Actually, you would cut down on context switches as you ship packets between kernel and user-space. This allows you to do all kinds of intelligent filtering and other header processing that can vastly improve latency in gateway systems (proxies, routers, VM hosts, etc.)

dgemm 10y ago

Saving an interrupt per packet. It's far fewer context switches to process packets in a busy loop.