From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4724B3B29E for ; Fri, 17 Mar 2017 05:02:26 -0400 (EDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 59A4176E9; Fri, 17 Mar 2017 09:02:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 59A4176E9 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=brouer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 59A4176E9 Received: from localhost (ovpn-200-33.brq.redhat.com [10.40.200.33]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1B61E627DD; Fri, 17 Mar 2017 09:02:21 +0000 (UTC) Date: Fri, 17 Mar 2017 10:02:14 +0100 From: Jesper Dangaard Brouer To: Eric Dumazet Cc: Michael Richardson , bloat , brouer@redhat.com, Dave Taht , Markos Chandras Message-ID: <20170317100214.600bc15f@redhat.com> In-Reply-To: <1489681664.28631.221.camel@edumazet-glaptop3.roam.corp.google.com> References: <27209.1489679549@obiwan.sandelman.ca> <1489681664.28631.221.camel@edumazet-glaptop3.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 17 Mar 2017 09:02:26 +0000 (UTC) Subject: Re: [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: Fri, 17 Mar 2017 09:02:26 -0000 On Thu, 16 Mar 2017 09:27:44 -0700 Eric Dumazet wrote: > On Thu, 2017-03-16 at 11:52 -0400, Michael Richardson wrote: > > Dave Taht wrote: > > > Is it faster to execute 17 bpf vm instructions on (nearly) every > > > packet, or to use all that old stuff? > > > > My understanding is that there is a JIT for ebpf. > > ebpf is pretty fast. To Dave what kind of arch are you running on? AFAIK you were running on MIPS right? Just checked the kernel tree and I was surprised to see a bpf JIT for mips: $ ls -1 arch/mips/net/bpf_jit* arch/mips/net/bpf_jit_asm.S arch/mips/net/bpf_jit.c arch/mips/net/bpf_jit.h But I don't know what state it is in (Markos?) > > > 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. The main point for getting performance out of eBPF is to avoid writing a generic framework that need to handle everything. The point is only to emit the instructions you need for your specific use-case. You should think about eBPF as a programmable policy (that we don't need/want to add to the kernel code and maintain forever) See this talk: https://github.com/iovisor/bpf-docs/blob/master/XDP_Inside_and_Out.pdf > Note that you can use C to write your parser, then use LLVM to > generate native eBPF code. Yes, that is how I use eBPF, writing restricted-C that LLVM compiles into eBPF code. You can look at examples in the kernel git tree under samples/bpf/ I've tried to make it easier to get started working with the LLVM setup by: (1) providing example code that compiles outside kernel tree: https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/samples/bpf (2) started documenting howto use eBPF: https://prototype-kernel.readthedocs.io/en/latest/bpf/index.html (3) Giving a talk on howto use it: http://people.netfilter.org/hawk/presentations/OpenSourceDays2017/ https://opensourcedays.org/business/talk?speaker_id=84 -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer