From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 07:00:19 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 CE7F16DB for ; Tue, 6 Aug 2013 07:00:19 +0000 (UTC) (envelope-from alnsn@yandex.ru) Received: from mail.o2.co.uk (vader.london.02.net [82.132.130.150]) by mx1.freebsd.org (Postfix) with ESMTP id 95DBC2BCD for ; Tue, 6 Aug 2013 07:00:18 +0000 (UTC) Received: from localhost (188.29.164.51) by mail.o2.co.uk (8.5.140.03) (authenticated as nasonov) id 51FB540B00C0FF24; Tue, 6 Aug 2013 07:59:10 +0100 Date: Tue, 6 Aug 2013 07:59:03 +0100 From: Alexander Nasonov To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Message-ID: <20130806065903.GA2835@x1000.localdomain> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> <20130805214621.C000D14A1C3@mail.netbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130805214621.C000D14A1C3@mail.netbsd.org> X-Operating-System: Linux 3.4.0 on armv7l X-SHELL: /bin/bash X-FCEDIT: /bin/ed X-EDITOR: /usr/bin/vi X-VISUAL: vim User-Agent: Mutt/1.5.21 (2010-09-15) Cc: tech-net@netbsd.org, freebsd-net@freebsd.org, Alexander Nasonov 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: Tue, 06 Aug 2013 07:00:19 -0000 Mindaugas Rasiukevicius wrote: > Yes, I may want to keep the state in the memory store or pass the arguments > through it, since the accumulator might not be enough. You have access to a whole packet, why do you need to pass additional arguments through the store? I'm worried about introducing tight coupling between these two very different environments and adding "sugar" for easy interaction is a big step in this direction. > If you prefer getter > and setter to perform a boundary check and enforce uint32_t type, I am fine > with that. Although BPF_MEMWORDS constant and words storing 32-bit values > stayed since 80s.. it is not going to change. > > However, abusing void * is wrong. Once bpf_filter(9) is adjusted to take > an opaque struct bpf_ctx *, the memory store ought to be moved into it. Ah, you plan to generalize scratch memory. It's probably fine but don't generalize too many things because people (me at least) want to be able to recognize the original bpf and its orignal design. Please note that I allocate scratch memory on the stack in bpfjit. If you change scratch memory to be under bpf_ctx, you will need to reimplement quite a lot in bpfjit code. > The rationale behind it is that we might want to handle out-of-range in the > byte-code without breaking the flow. This can be a valid case for BPF_COPX. > Just BPF_RET 0 seems a limitation, but I do not have a strong feeling here. I'd keep it consistent with bpf. Alex