Line rate 10Gbit/s packet processing on FreeBSD with netmap

[muppetman]

This is really very interesting.

I work with Juniper routers and switches all day and every day, the thing I love about them is they're built on top of FreeBSD (now called JunOS, but it still harks back to FreeBSD when you drop to the shell)

Something small and light and fast, running on FreeBSD with this added would be perfect for customer CPE equipment or for non-essential routing tasks.

Very impressive, I look forward to seeing where this goes.

[tptacek]

The data path on a Juniper isn't passing mbufs around the FreeBSD IP stack, is it? It's FreeBSD command-and-control, but my understanding is that the packet processing itself might as well be its own rtos.

[sc68cal]

As many have said on -CURRENT: Thanks for the great work. Do you plan on getting this merged into the FreeBSD tree, and maintaining it?

[lrizzo]

yes to both questions. merging should start very soon.

[smutticus]

This is impressive. How is the performance on different packet sizes? Most real world loads would require far fewer than 14.88Mpps since most packets would be equal to MTU. So I'm wondering if performance would increase or decrease with packet size.

[lrizzo]

please look at the paper linked to the url, which defines the problem and the metrics in more detail.

[codepoet]

Great! Maybe you could compare this with http://www.ntop.org/PF_RING.html for Linux?

[lrizzo]

The "old" pf_ring is only meant for packet capture and involves packet copies, so it is several times slower than netmap. There is a newer "Direct Network Access" (DNA) version of pf_ring which avoids copies and has the same performance of netmap, but is much more fragile because in DNA the userspace program writes directly into the NIC registers and rings (so it can crash the entire OS), whereas in netmap the NIC programming is filtered by system calls.

[mateuszb]

Very clever solution on stack bridging. +1