From owner-svn-src-user@FreeBSD.ORG Wed Oct 24 12:35:58 2012 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A6B8525; Wed, 24 Oct 2012 12:35:58 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 34C458FC0A; Wed, 24 Oct 2012 12:35:56 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so218566bkc.13 for ; Wed, 24 Oct 2012 05:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6t30xvVauTQlbHQKDmAx1QpI12R1A4QleAVxUIpXhKw=; b=sPvP2ecY5zlMWuaOeCLY9j6SO2xxn4BrlsfnUCxaRjZYrX6DikNGaaUP6ZpfnghpbU DD5tRC2K3ZXBoY38c4vuRXEXBE+fiuCLyXZ74et7O4dM3hidPP93aSml/j0yVtTNilDE ReAzaEEwZf5nUrE61rKbxWLBw6nyZnwj6DqLtCA5ThsStw0N/+gO+SB7aydOqSvcKCPI qKIG/cKUBuqiB55RBXf9JUv85DuiH8EP61iPjvA8S9NztNzyxMjvCex4zKL88LTwz2Y5 O6mqbAh2Cj6MuNHvyMW5P+ZnERobMGBqEsTAcpUNWz4JY8KREV1gRb1733bTl1ZWpFkC wrXw== MIME-Version: 1.0 Received: by 10.204.145.214 with SMTP id e22mr4621270bkv.133.1351082155747; Wed, 24 Oct 2012 05:35:55 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.204.143.148 with HTTP; Wed, 24 Oct 2012 05:35:55 -0700 (PDT) In-Reply-To: <5086F086.6080000@freebsd.org> References: <201210231926.q9NJQnqu039908@svn.freebsd.org> <5086F086.6080000@freebsd.org> Date: Wed, 24 Oct 2012 14:35:55 +0200 X-Google-Sender-Auth: opJ6lVGy1BhwZcdWG_AAWpKPEuo Message-ID: Subject: Re: svn commit: r241966 - user/andre/tcp_workqueue/sys/net From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: src-committers@freebsd.org, svn-src-user@freebsd.org X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 12:35:58 -0000 Hello Andre, i have since forever wanted to merge this but never got to it. https://github.com/bsdperimeter/pfsense-tools/blob/master/patches/RELENG_9_0/pfil.RELENG_9.diff This has been used in pfsense quite sucessfully. It allows to reorder the pfil hooks based on names of registered hooks using sysctl. On Tue, Oct 23, 2012 at 9:31 PM, Andre Oppermann wrote: > On 23.10.2012 21:26, Andre Oppermann wrote: >> >> Author: andre >> Date: Tue Oct 23 19:26:49 2012 >> New Revision: 241966 >> URL: http://svn.freebsd.org/changeset/base/241966 >> >> Log: >> Extend PFIL hooks with explicit hook ordering and reinjecting of >> packets into the chain after a particular hook. >> >> Add pfil_add_hook_order() taking a numerical value between 0-255 >> to specify the relative position of this hook in the list of all >> hooks. Lower numbers have higher ordering (ie. will run first). >> Within a particular order value the last added will be the first >> to run. Three fixed positions are defined: >> PFIL_ORDER_FIRST 0 >> PFIL_ORDER_DEFAULT 200 >> PFIL_ORDER_LAST 255 >> >> Previously the order was non-deterministic and dependent on the >> ordering of the add hook calls. The last added would always >> become the first to run. >> >> Non-ordering aware pfil consumers using the pfil_add_hook() call >> get PFIL_ORDER_DEFAULT assigned resulting in the previous ordering. >> >> The ordering is determined at hookup time by the pfil consumer >> and no tool for later manual re-ordering is provided. Most well >> known pfil consumers are expected to have a predetermined preferred >> position in the order. A tool or sysctl reporting the order of >> hooked pfil consumers will be provided later. >> >> Add pfil_run_inject() taking an opaque cookie value obtained with >> pfil_get_cookie() after the hook is added. Processing of the hook >> chain skips all hooks until after the one with the same cookie. >> The cookie is valid as long as this hook remains hooked. If no >> cookie is found processing is started with the first hook again. >> If the cookie is invalid processing of all hooks is effectively >> skipped. >> >> With this pfil hooks consumers can dequeue packets for further >> processing and later re-inject them with the next hook. > > > Besides the obvious ordering solution to the exiting pfil consumers > my idea is to explore converting most of ether_input/output and IPsec > processing to pfil hooks. This will need some further definitions > for the default PFIL_ORDER points but that'll happen when there's > some practical experimenting with running it. > > -- > Andre > -- Ermal