From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 17:47:03 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 01D0413D for ; Wed, 7 Aug 2013 17:47:03 +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 C72EF2C18 for ; Wed, 7 Aug 2013 17:47:02 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 9E1C214A0F7; Wed, 7 Aug 2013 17:47:01 +0000 (UTC) Date: Wed, 7 Aug 2013 18:46:41 +0100 From: Mindaugas Rasiukevicius To: Alexander Nasonov Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <20130806065903.GA2835@x1000.localdomain> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> <20130805214621.C000D14A1C3@mail.netbsd.org> <20130806065903.GA2835@x1000.localdomain> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130807174701.9E1C214A0F7@mail.netbsd.org> Cc: tech-net@netbsd.org, 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: Wed, 07 Aug 2013 17:47:03 -0000 Alexander Nasonov 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. Why is it a problem? Given that the byte-code and the functions would come from the same source, some coupling seems natural to me. It is simplistic anyway: some already parsed offsets or values could be passed through the memory store. > > 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. Well, you suggested getter/setter. :) > 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. Is it really a lot? We can waste some cycles and just copy them into the stack (if there are any initial values). -- Mindaugas