From owner-freebsd-net@FreeBSD.ORG Thu Aug 29 15:27:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A30AEB10 for ; Thu, 29 Aug 2013 15:27:58 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DB7E2075 for ; Thu, 29 Aug 2013 15:27:58 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 030C414A13C; Thu, 29 Aug 2013 15:27:56 +0000 (UTC) Date: Thu, 29 Aug 2013 16:27:41 +0100 From: Mindaugas Rasiukevicius To: Darren Reed Subject: Re: BPF_MISC+BPF_COP and BPF_COPX (summary and patch) In-Reply-To: <521F4522.5070403@netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130822101623.3837E14A21D@mail.netbsd.org> <521F4522.5070403@netbsd.org> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:27:58 -0000 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. > 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. -- Mindaugas