svn commit: r276747 - head/sys/netpfil/pf

[Gleb Smirnoff]

On Thu, Jan 08, 2015 at 12:49:45AM +0000, Bjoern A. Zeeb wrote:
B> > B> > AFAIU, from the PR there is some panic fixed. What is the actual bug
B> > B> > and why couldn't it be fixed with having per-vnet thread?
B> > B> 
B> > B> You don’t 30000 whatever pf purging threads on a system all running, possibly competing for some resources, e.g., locks?
B> > 
B> > Isn't a vnet, which is a jail, already a set of a dozen of processes? So,
B> > if you are speaking of "30000 whatever pf purging threads", then you
B> > already mean “1 mln whatever processes".
B> 
B> jail/VNETs can exist without a single process attached.
B> 
B> But I guess the point is that there is only so much work we can do at the same time and we should be very careful in what we try to parallellellellize as with 5 vnets it might be fine, with a couple of thousand you may keep a system busy with itself.

Let's admit that thousand of vnets all running pf is bizarre design
and has no practical application.

B> > Speaking of pf purging threads competing for resources. If someone wants
B> > really independent pfs in vnets, then locks should be virtualized as well.
B> 
B> No please don’t.  The only places where we “virtualise” locks for VNETs is part of data structures which are vnet specific (virtualised).

And the pf state tables (the data the purge threads work on) of course
are vnet specific (virtualised).

-- 
Totus tuus, Glebius.