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

[Dave Taht]

On Thu, Mar 16, 2017 at 9:27 AM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> On Thu, 2017-03-16 at 11:52 -0400, Michael Richardson wrote:
>> Dave Taht <dave.taht at gmail.com> wrote:
>>     > 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:
>>
>> I have no data for you.  Andrew McGregor might know more?
>> My understanding is that there is a JIT for ebpf.
>
>
> ebpf is pretty fast.
>
>>
>>     > 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 -
>>
>> tcpdump just exposes the libpcap compiler.  It has many annoying limitations.
>>
>>     > 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?
>>
>> Yes, people have produced them, but they go nowhere because they are too
>> specialized, or too general.  The question is: are you trying to build a tcp
>> stack that punts packets at applications, or do "analysis" --- which I interpret
>> to mean to collect statistics.

Yes and no. Being able to toss "rawer" captures into a database and be
able to sanely query against it was the goal of capturing multiple
"views" of a wifi network.

Another goal was to be able to write a solid packet parser for any
given protocol I used babel as my example, but, say, http2....

People are perpetually using the ip6 match in tcpdump, when that's incorrect.

> Note that you can use C to write your parser, then use LLVM to generate
> native eBPF code.

Ideally I wanted to be able to express that like this:

https://github.com/grg/parser-gen/blob/master/examples/headers-enterprise.txt

Preprocess it, then use llvm to compile it down to bpf.

I'm *really* impressed by the level of tool support emerging for ebpf,
but it's still essentially writing assembly when I'd rather use an
equivalent of bison or peg. If taking that massive step backwards is
the right thing, to build that tool (if none exists)... well... ok.

>
>
>>
>>     > C) Are vendors like mellonox or others doing network offloads parsing
>>     > bpf or ebpf directly yet?
>>
>> I don't know.
>
> Netronome is (kind of)
> drivers/net/ethernet/netronome/nfp

Cool.  Looks like I'd have to hold a bufferbloat.net bake sale to get
one of those to play with, tho.

>
>



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