From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2FBE23B29E for ; Thu, 16 Mar 2017 11:19:35 -0400 (EDT) Received: by mail-qt0-x234.google.com with SMTP id r45so40283698qte.3 for ; Thu, 16 Mar 2017 08:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=M47tYWA6nBZN2jmt4vWzP9GRaq4s8evUS/4IH7JQYLs=; b=nXfSGAq6l1wFFkONxoRG4zFSbdSsUDkCEXzc3A/aMaK5TC9zsSm8gJB2DxHQ9/A/3T vzPy4ITEi8r/iMLETyuyJ4bJiC+FCQBU4Hta5nKxenra1zI6tIvoVOGQ7880GEcf6emD 6ozsNwdJY9VDicRMRdZi3P/kyW5f7do5Gz3xHZlKCFmngnOqnTQH8WZbvWX8jfi9Xhhc fU8MdqKkF5T1BGVqOJH/onXumWLAbB9CBW1UnkYj5cI0UCRlIqWbfxhvvjkBVLtTNa+2 WFFl017p5B5duNw7C7pcpIike1v5gB6vThonex7H+XsrZe0CegxMInaXGxLcO3YU903t 2pLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=M47tYWA6nBZN2jmt4vWzP9GRaq4s8evUS/4IH7JQYLs=; b=V4JZC05CcjTm6piYoLwoLF6/a2UMhNuAUvSlBb7RZZC7pRpebciFiETd8B9RInPMEp MlxQ2L0vi639uOkT042BI7khBNreYDoVyzu5ZtLRUjxpRpO5GGhOv1kaKpTK8yNTPUTq W11mz4d8MglNVxdo0mo6Be/6DR+VWLmXbrvP7IJ0eJ9QuX0QrWZb2KY1sDKi8Ifv++pJ Ylh4pb9bQZUt+UX3vx4tRPoif+xC6+rqOd7XJVP07Pm1ePsN9oPRUtkcFWNYpwxuH+xA 6uXLZ+lo1QvgcJsBRoPucQjz2uEOW93GQgkAow5STwCtgpP3ux6mn8YMgq2T7qbR2cNg o6+w== X-Gm-Message-State: AFeK/H16R8I6s0IgNECPQFVtF5N8p8OsPrNhbJFRulXz/XFhYhhU0YxhyPiry8Ag7IQOvVoUj4XKV43b+hydAA== X-Received: by 10.200.45.59 with SMTP id n56mr8834229qta.137.1489677574107; Thu, 16 Mar 2017 08:19:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.142.132 with HTTP; Thu, 16 Mar 2017 08:19:33 -0700 (PDT) From: Dave Taht Date: Thu, 16 Mar 2017 08:19:33 -0700 Message-ID: To: bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Bloat] high speed packet and protocol processing in userspace? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 15:19:35 -0000 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? --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org