[Bloat] high speed packet and protocol processing in userspace?

Dave Taht dave.taht at gmail.com
Thu Mar 16 11:19:33 EDT 2017


Now that the big make-wifi-fast phase is complete, multicast is next.

I'm finding that I need to be delving into things that are happening
at sub-4ms intervals, and at high speeds (think: 802.11ac). While
flent can be used to drive such tests, actually taking apart the
packet captures has been something that I have generally fallen back
on things like wireshark, libpcap, and tcptrace to analyze.

Anyway, last month, after taking apart what I'd have to do to this code,
https://github.com/dtaht/airtime-pie-chart

to better be able to take apart multicast reception from multiple wifi
points, I ran away screaming. Then I started to look at new, cool
things, like ebpf - which would let me build histograms and so forth
in real time, and a variety of new efforts like fd.io, and so on, and
yet still is this semantic gap between "what I want", and "how to do
it".

So I'm *stumped* about a few things and I thought I'd ask the list.

A) How much overhead on a box or protocol can come from using raw
sockets and a ton of bpf?

Example: If I converted a daemon that currently uses classic means to
filter out packets, registering a udp port, turning on a multicast
group, listening on an address - and changed it to just basically
using a bpf filter to do all that instead) - how much is that going to
hurt, nowadays?

Is it faster to execute 17 bpf vm instructions on (nearly) every
packet, or to use all that old stuff?

bpf example for the babel protocol:

https://github.com/dtaht/libv6/blob/master/clients/tabalb/babel.bpf

(the crazy advantage of this idea is that I can better measure actual
packet loss, crc failures, wifi retries, etc, due to corruption,
across an entire wifi network)

B) Are there any means of easily abstracting deeper protocol
processing into a higher level grammar, better than tcpdump? I found
one tool, that I like conceptually - for deeply decoding a protocol -

https://github.com/grg/parser-gen/blob/master/README.parse-graphs.md

(which I got from the *excellent* paper:
http://yuba.stanford.edu/~nickm/papers/ancs48-gibb.pdf )

...but it just outputs verilog at the moment.

When I (as an example), look over the hand written parser for babeld's
(mere) 13 messages, I really, really want to be somewhere else. (and
it's a pretty good parser!)

That sort of processing does not seem amiable to a peg or bnf grammar
(but see above grammar and/or examples), and yet I'd really like to be
writing things that are provably correct and robust... that compile
down to something really efficient... quickly... with minimal
thought... that hopefully someone else has already written!

(babel's parser is *nothing* compared to looking at the mac80211 headers)

I've googled, and thunk, and maybe I'm merely asking the wrong
questions, and "the packet analysis tool to end all tools" already
exists?

C) Are vendors like mellonox or others doing network offloads parsing
bpf or ebpf directly yet?

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


More information about the Bloat mailing list