From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 10:33:06 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 225CFB5F for ; Thu, 8 Aug 2013 10:33:06 +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 E859F26B1 for ; Thu, 8 Aug 2013 10:33:05 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 2542614A2A9; Thu, 8 Aug 2013 10:33:03 +0000 (UTC) Date: Thu, 8 Aug 2013 11:32:45 +0100 From: Mindaugas Rasiukevicius To: Alexander Nasonov Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <20130807201712.GA2042@x1000.localdomain> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> <20130805214621.C000D14A1C3@mail.netbsd.org> <20130806065903.GA2835@x1000.localdomain> <20130807174701.9E1C214A0F7@mail.netbsd.org> <20130807201712.GA2042@x1000.localdomain> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130808103304.2542614A2A9@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: Thu, 08 Aug 2013 10:33:06 -0000 Alexander Nasonov wrote: > Mindaugas Rasiukevicius wrote: > > 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. > > You surely have some picture in mind but I can't get it. I'm a bit > worried that two different environments may look unnatural when married > together. OK, but you did not explain why is it a problem i.e. why is it worrying? > Perhaps, you should right a proposal with some use-cases to support your > points. They are simple: consider detecting IP version and calculating the offset to L4 header. There is no reason to duplicate this work in the byte-code and the coprocessor. If one of them does it - let's just save 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. :) > > Yeah, please write a proposal ;-) > int bpf_get_memword(const bpf_ctx_t *c, size_t i, uint32_t *val); int bpf_set_memword(bpf_ctx_t *c, size_t i, uint32_t val); You prefer something like this? -- Mindaugas