> On Jan 27, 2015, at 4:08 PM, Antoine Beaupré <anar...@koumbit.org> wrote: > > On 2015-01-27 13:57:20, wishmaster wrote: >> Have you consider to use netmap-based ipfw instead pf in DDoS mitigation? I >> think you should. And without any network ''haks'' like polling. > > My understanding of netmap was that it wasn't useful for packet > forwarding, because its design is for transmitting packets directly to > userland faster, whereas routers dataflow stay mostly in the router…
the problem is that the “data flow” in freebsd isn’t very fast. (I’d go so far to say, “broken”, but that’s throwing rocks.) But as long as the window is already broken: the rtentry locking is a good example of how the stack is broken. the lack of FIB caching is another issue and the packet-at-a-time-to-completion is another. (no batching) So ’N’ packets worth of address lookups, (ACLs, …, etc) at a time. Just like “Click” showed a decade ago (and where the polling mode was of use). But it’s trivial to build a packet forwarder (more L2 than L3, but all things are possible) using netmap (or dpdk) that smacks the freebsd (and linux) stacks with a large stick. The netmap code comes with a “bridge.c” example that is just that, a dead-simple bridge. Another example, “netmap-fwd” runs at 14.88Mpps between two 10Gbps interfaces. (Neither pf or the kernel-resident ipfw will come close, both are more than an order of magnitude slower.) Here’s something a bit more than “dead simple”: https://github.com/caladri/brilter <https://github.com/caladri/brilter> This would be even faster if Juli would use one of the Lua JITs, e.g.: http://wingolog.org/archives/2014/09/02/high-performance-packet-filtering-with-pflua And if you want to go ‘full tilt’, Click runs on top of netmap since 2012: https://github.com/kohler/click/commits/netmap <https://github.com/kohler/click/commits/netmap> (the code is in the master branch, too. use master.) As for the netmap-ipfw code, it’s 6.5Mpps to 10Mpps (later editions of the code: http://freebsd.1045724.n5.nabble.com/ipfw-meets-netmap-6-5-Mpps-in-userspace-td5734014.html <http://freebsd.1045724.n5.nabble.com/ipfw-meets-netmap-6-5-Mpps-in-userspace-td5734014.html> > I'm hesitant in switching back to ipfw, considering how nice the > featureset and syntax of pf is. But if that's what's needed to restore > sanity… pf is sane? No, I don’t think so. (yes, it does say “pf” at the front of “pfSense”. so what? I mean, have you looked at the code?) Turn off polling, unless you know you need it. You’ll know you ‘need it” if you start making changes to the stack. There is a lot of “mystery meat” in most fields, and the field of computers / operating systems contains it’s share. As a somewhat associated example, Intel says, "hyperthreading helps (networking) performance!” 6wind says this too. freebsd developers say, "hyperthreading hurts performance”. In the end, it depends what is stalling the CPU. Hyper-threading is a trick to share the write pipes on the core, and traditional implementations of memcpy() will fill these pipes (call them buffers if you like.) And the stack does a lot of “memcpy()” (I’m waiting for the yowls of “we zero-copy!”, because anyone who asserts this just hasn’t looked at the stack.) There are tricks (if your code is interleaving access to the write pipes well, you’ll see more benefit. This really wants cache-aligned data structures, etc.) So, that’s just a long-winded “YMMV”. Jim _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
