From owner-freebsd-net@FreeBSD.ORG Fri Aug 30 06:36:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 76FF469D for ; Fri, 30 Aug 2013 06:36:04 +0000 (UTC) (envelope-from darrenr@netbsd.org) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 320AB292A for ; Fri, 30 Aug 2013 06:36:03 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5FA4A21112; Fri, 30 Aug 2013 02:35:57 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 30 Aug 2013 02:35:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:reply-to:date :in-reply-to:references; s=smtpout; bh=uQRrtrMIsTRHTH+iZO+aVGzrn Cg=; b=FxRCpiQRaNosfpw3JQHSY5MXRxQX1snl65oPfMF2AeQHhTH1LEx0LI9Gx k8qzeRHcvMRNcIFT+xs9dl+PWWZjziGKG5HKFNSYOF7hqU+9pk0pgpb88skv1wXB Y3C8vGqOSD4Jqj6JqYFlJhFBX8hkecthHm7tP441HcyPi3hx2M= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 29BD410B747; Fri, 30 Aug 2013 02:35:57 -0400 (EDT) Message-Id: <1377844557.1741.15873957.4FB18641@webmail.messagingengine.com> X-Sasl-Enc: 0q2qO4KgjuowgnRYLhFjsXDtthNOA8HB6tR/zmDNiNpB 1377844557 From: Darren Reed To: Mindaugas Rasiukevicius MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-f98c0b0f Subject: Re: BPF_MISC+BPF_COP and BPF_COPX (summary and patch) Date: Fri, 30 Aug 2013 08:35:57 +0200 In-Reply-To: <20130829152757.030C414A13C@mail.netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130822101623.3837E14A21D@mail.netbsd.org> <521F4522.5070403@netbsd.org> <20130829152757.030C414A13C@mail.netbsd.org> Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: darrenr@netbsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 06:36:04 -0000 On Thu, Aug 29, 2013, at 05:27 PM, Mindaugas Rasiukevicius wrote: > Darren Reed wrote: > > Mindaugas Rasiukevicius wrote: > > > Hi, > > > > > > OK, to summarise what has been discussed: > > > > > > - Problem > > > > > > There is a need to perform more complex operations from the BPF program. > > > Currently, there is no (practical) way to do that from the byte-code. > > > Such functionality is useful for the packet filters or other components, > > > which could integrate with BPF. For example, while most of the packet > > > inspection logic can stay in the byte-code, such operations as looking > > > up an IP address in some container or walking the IPv6 headers and > > > returning some offsets have to be done externally. The first existing > > > user of such capability would be NPF in NetBSD. > > > > > > > I'd argue that the IPv6 problem is of such a generic nature that > > it deserves its own instruction/s. We may look at IPv6 today and > > think nobody uses it much but over time that is going to change. > > Thus there will be an outcome not possible with co-processor > > approach if an instruction is created for that purpose and is > > common across all platforms through libpcap. Unless the IPv6 > > problem is too complex for a single instruction (this has not > > been demonstrated.) In that case maybe BPF itself needs to evolve > > such that it can support more complex instructions. > > This is a separate issue. Feel free to propose an new instruction to > parse IPv6 headers. To do this requires understanding what we want to do with the extension headers. Do we want to: 1) find a particular extension header 2) find the start of the last extension header 3) get a list of all extension headers (including L4 protocols) 4) as per (3) but also their offset 5) ... anything else? For example, if you were to write a tcpdump expression to filter fragments for IPv6, what should the BPF look like? Alternatively if you wanted to display all packets that had both a routing header, fragment header and were UDP, how complex should the BPF instruction set that results be? > > The current implementation of BPF makes it very hard to expand > > the instruction set without impinging on the ability to make > > future changes due to the way in which instructions are codified > > into 32bits. Whilst the method of supporting a co-processor gets > > around that, it does so in such a generic fashion that it becomes > > too easy to use it as a bit-bucket for anything you think might > > be a good idea if BPF could do without really evaluating if it > > should do. > > It is certainly possible that some operations, which will be > implemented using BPF coprocessor, will be useful in general. > Again, whether such operations should be "promoted" to be > new BPF instructions or there should be a global "standardised" > coprocessor or how BPF should evolve (including RISC vs > CISC-like instruction set debate) is a separate discussion. Oh, my comment above was much more open than that. Effectively what I'm proposing is moving beyond the single 32bit instruction word for BPF: maybe it is time for BPF to join the 64bit world. The current design of BPF enforces a certain amount of rigour because it can't be expanded ad-hoc due to the design and the implementation of that design. It forces you to consider "should I do it" not just "can I do it." My comment above about the "should" part refers to the co-processor argument taking away a certain amount of engineering discipline that currently goes with BPF. Currently you can't just use it for "anything and everything." Cheers, Darren