From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 BD9023B29E for ; Thu, 16 Mar 2017 12:44:34 -0400 (EDT) Received: by mail-qt0-x229.google.com with SMTP id x35so42506570qtc.2 for ; Thu, 16 Mar 2017 09:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rPxQGz4d5jv5Gb8itkRTbbaMKt/z0hx/lG64sVwoAto=; b=WqsG33l7RWPRX2xhuAcZ5iSdyL/Vb6mS4vKR0b4SF9Q3E/obRsXxWnNS4v6KMiMNsZ DudBTsG6zatCiA1wzbNUQbdDW0hKQGzBoy+dcxiVxuaZEU5DXhki2IvAlfGqhs6aQfDf EKBJcH2HXcg0hIx2ien2D/O26SaKECyW/zLMm0uDZv3gDjD1qICCF++VlgrjUkhbFdLM I1AwOLk78pvBfjYp8zzjFqr5PHISVgAylnxkplMr1J4q/6p+zVSCvbk2jp2/lD7NKIhN siRCHibbXIzfpmMBTir7XxNp8qU7HePr5mxxjIPlWvy9+gHLBXStSmeo9hgYFS4gxu3E HU8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rPxQGz4d5jv5Gb8itkRTbbaMKt/z0hx/lG64sVwoAto=; b=syCXA5tadF01zVIW304FSsgYUepiSPAixq9nLNTuOU6VTiTqTt5i3pZo/bHxVHBW45 kKRmYWr2yP9R+OEw8SeNptcpuTKY24tYVOrSBsqucudoFNk/+EVgSkGQKFasKbQqlXVt NpMC3/x1V6J6faTZQmWa5Qy91dESUEFWbTu+XPGB79CD4S6+tkuwNk8BzgUUJFglWBvv rTQ8xUe45ddOJJuR8C4kVmpvTEHuN0lspjl0pH5DwCKkjk5N6yWu8XwkPvm+k8pSuWwu jcY2n0qd6woZHHNuov46bwcWD+oEzgRveCZFJ0tksJxQvzbwEnNc40QwmB55tQwdP6Pc qSBg== X-Gm-Message-State: AFeK/H2yXyDZGtus0DW1arfbYXpwgtUI6fapYL6xbMDObFEtG9mc8A3JGLPamsWYda7ITxV7YAi9HID/WdoSeA== X-Received: by 10.237.56.232 with SMTP id k95mr8991158qte.10.1489682674149; Thu, 16 Mar 2017 09:44:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.142.132 with HTTP; Thu, 16 Mar 2017 09:44:33 -0700 (PDT) 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> From: Dave Taht Date: Thu, 16 Mar 2017 09:44:33 -0700 Message-ID: To: Eric Dumazet Cc: Michael Richardson , bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 16 Mar 2017 16:44:34 -0000 On Thu, Mar 16, 2017 at 9:27 AM, Eric Dumazet wrot= e: > 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? >> >> > 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 proce= ssing >> > 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 limitat= ions. >> >> > 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 i= nterpret >> 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 incorrec= t. > 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.t= xt 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 pars= ing >> > 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. > > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org