pf + vimage patch

[Thibault Noel]

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 <glebius at freebsd.org>

> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "
> freebsd-virtualization-unsubscribe at freebsd.org"
>