From owner-freebsd-pf@FreeBSD.ORG Thu Jun 6 13:30:44 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D14C6BE3; Thu, 6 Jun 2013 13:30:44 +0000 (UTC) (envelope-from titi5187@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 765361198; Thu, 6 Jun 2013 13:30:44 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id s9so7105216iec.30 for ; Thu, 06 Jun 2013 06:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GSpRu686kn7cS675oheBZtUm+9tcakEOjGvbZuLM0C0=; b=hpYiz3ocl2invRhNmAVQ450cz/9DVr0t64JMHDT9tZRPZ6wVMTgXj20YOFrx7SzFqN WhkSo6UkhAILyYyCpRGcIIxdzLTc/lqWCq7LmSUI7tKm0tmUlXgI1lR2cuNdQ9f14BKz v7TQ+UWXVAEDCU65W5J4OwhOGbqoQtxCiNV+xoM7HnY+kCzRi8Ydw9Vu4gKVdwDwTHFY lZf7om2JcUPu0R1PrWRjO/qpD+HyZ4wKtrbX+/uhMRJ/gKoKCjbi4P9/6cXf/BQPFJ5F wa0XPHCqmBAaRVkFkQnreAq54HwDmfPmdQ/k+16g/wufoIH44XoNlttwTLSrNM/LaqGz vwYw== MIME-Version: 1.0 X-Received: by 10.50.47.105 with SMTP id c9mr5808925ign.50.1370525444206; Thu, 06 Jun 2013 06:30:44 -0700 (PDT) Received: by 10.64.89.71 with HTTP; Thu, 6 Jun 2013 06:30:44 -0700 (PDT) In-Reply-To: <20130606122855.GC14667@glebius.int.ru> References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> <51B065F5.4080209@gmx.com> <20130606122409.GA10459@gmail.com> <20130606122855.GC14667@glebius.int.ru> Date: Thu, 6 Jun 2013 15:30:44 +0200 Message-ID: Subject: Re: pf + vimage patch From: Thibault Noel To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Mikolaj Golub , "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:30:44 -0000 Hi, I quite agree with Gleb Smirnoff on the possibility of avoiding a reboot after each compile. I don't now if it's a good moment to speak of this, but I observed that if pfsync is active in the kernel, it will use its state table even if nothing is set in the rc.conf. I think that if no parameters is written in the rc.conf (syncpeer, etc. ..) it will not be usefull to create lock to block the state table thus it will slow pf. What do you think ? 2013/6/6 Gleb Smirnoff > On Thu, Jun 06, 2013 at 03:24:10PM +0300, Mikolaj Golub wrote: > M> > >> -VNET_DEFINE(u_long, pf_srchashsize); > M> > >> -#define V_pf_srchashsize VNET(pf_srchashsize) > M> > >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, > CTLFLAG_RDTUN, > M> > >> - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes > hashtable"); > M> > >> +u_long pf_srchashsize; > M> > >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, > CTLFLAG_RDTUN, > M> > >> + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); > M> > >> > M> > > > M> > > Why do you have to devirtualize these variables? Are per vnet > M> > > hashtables sizes not useful or do they cause issues? > M> > > M> > Per VNET variables are not useful for pf_hashsize and pf_srchashsize > M> > since these values are RO and cannot be modified at runtime. > M> > M> Indeed. I missed RDTUN flag. > M> > M> > module unload is broken:( Maybe it can be fixed at a (bit) later date? > M> > M> I don't think Gleb will be happy with this. Some time ago he removed > M> some vimage related stuff to prevent crashing on module unload (see > M> r229849). Actually your patch looks like a partial revert of that > M> commit. So I think you need to think about this issue from start. At > M> least it should not crash non-vimage kernel and there should be > M> understanding how to fix it for vimage kernel. Your approach with > M> keeping only one purge thread might make it simpler. > > True. It is very much appreciated that you are working on vimage + pf, > but breaking module unload isn't an option. > > When hacking on a part of kernel, having a possibility to avoid a reboot > after each compile is very important. > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to " > freebsd-virtualization-unsubscribe@freebsd.org" >