From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4921B3B29E for ; Thu, 16 Mar 2017 13:32:15 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E2CBBE240 for ; Thu, 16 Mar 2017 13:55:24 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AB1FE636BB for ; Thu, 16 Mar 2017 13:32:14 -0400 (EDT) From: Michael Richardson To: bloat In-Reply-To: References: <27209.1489679549@obiwan.sandelman.ca> <1489681664.28631.221.camel@edumazet-glaptop3.roam.corp.google.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m 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 17:32:15 -0000 --=-=-= Content-Type: text/plain Dave Taht wrote: > 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. years ago, I worked in the NPU space, and we created the language that I think you wanted. It was described here: https://www.ietf.org/archive/id/draft-nossik-pax-pdl-00.txt IPv4 patterns filters looked like this: PATTERN IP_v4_Hdr_For_ICMP { version UINT 4 == 4; ihl UINT 4 == 5; /* length == 5 : no options */ typeOfService UINT 8; totalLength UINT 16; identification UINT 16; flagReserved BIT 1 == 0; flagDontFragment BIT 1; flagMoreFragments BIT 1 == 0; /* last fragments only */ fragmentOffset UINT 13 == 0; /* first fragments only */ timeToLive UINT 8; protocol BIT 8 == IPPROTO_ICMP; /* ICMP */ headerChecksum BIT 16; sourceAddress BIT 32; destinationAddress BIT 32 } You could compile the patterns, and then instantiate fields at runtime if you needed to. (i.e: add constraints). Also merge patterns to select (a) or (b) in constant time (but not constant memory usage) Solidum (for whom I worked at the time) had a compiler that would turn this into ) patricia-tree filters that ran in hardware at wirespeed. But, APIs into ernels were hard to get accepted. In the end, only people willing to pay for this were TLAs who wanted to run regex's on traffic. Regex took lots of ram, but TLAs didn't buy many sockets. I would love to be able to recycle the compiler as open source; it could easily spit out EBPF, but generating assembly directly might be faster actually. The Patricia tree is basically jmp base+nextbyteofpacket., but stored more compactly. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljKzB0ACgkQgItw+93Q 3WXiPgf+Os0DhkC15nG4biF2D7cW1WPPqx4jqlKhMQmdQ1RoNlwm1m1nWu7K3OWu wbIjIl2b83tCLbGP+DcgwG/JWS6IEvZd3Y4Zkk84whqXM50vfoeiTZXwsgbPaJp7 3061qCfGkedhlyxtVkFX1INgTpM7QEtQ26+rm9Z7rDtyYSMZqpRCu92N1KPDjK9Q Wwdzl2dHJ8gST8OmZKxBCjR+0m3mDecMprvjMbS6YnbnV9S+YLRatGecC2I5kJf2 yVcNFcubUco/LPKCB7Svjw0yZqbPLlhkDmonb0CeF8qpoN+WOOKJsyiEtb4E7yJZ I0+Blkv+J5rUb2oI39P0VmcPe6FRsg== =7Bhy -----END PGP SIGNATURE----- --=-=-=--