From owner-freebsd-net@FreeBSD.ORG Thu Aug 29 11:52:54 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 1BB6D7AB for ; Thu, 29 Aug 2013 11:52:54 +0000 (UTC) (envelope-from darrenr@netbsd.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E21772053 for ; Thu, 29 Aug 2013 11:52:53 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8934321E1D; Thu, 29 Aug 2013 07:52:50 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 29 Aug 2013 07:52:50 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=rV1HpaiAO2+B9JYuOWptUO I8mCw=; b=jxApQHAH9+4DjI7KJYU9t1NyD/iGUEeQ0kTmZStIjyul6s5FrAkeK8 zEt5+WWjoWfMgeNmZMcRGDeXUpMmzZUAivY/cv3I8ipjvDDpHLh8fdoTccerxINE aeO82R1Aw16GKGf6wJeuXhZUdewbrzb4Z2svlSFuFJKY3tzhz/Ttg= X-Sasl-enc: 5xyMFwxwNbxr+WXDObK5YqBhIh2EwJC7pF0XWeaNtMwg 1377777170 Received: from [192.168.1.31] (unknown [203.206.138.26]) by mail.messagingengine.com (Postfix) with ESMTPA id F0915C00E84; Thu, 29 Aug 2013 07:52:48 -0400 (EDT) Message-ID: <521F4522.5070403@netbsd.org> Date: Thu, 29 Aug 2013 22:57:06 +1000 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX (summary and patch) References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130822101623.3837E14A21D@mail.netbsd.org> In-Reply-To: <20130822101623.3837E14A21D@mail.netbsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 11:52:54 -0000 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. 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. When it comes to looking up addresses in tables, I don't see the advantage in adding this to BPF to support NPF. My suspicioun is that the goal is to support expressing the entire rule as just BPF byte code. For rules, it makes no sense as the expensive operation (table lookup) could just as easily be done after the rest of the packet is matched with BPF. Or is there something else here at play that I'm missing?