[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: IPFilter issue in -current
On Nov 28, 2012, at 1:57 PM, Mike Pumford
> I think you are right. I'm running a 5-stable ipfilter firewall and it
> survives bittorrent traffic that maxes out my 24Mb/1Mb ADSL link and takes my
> firewall CPU to 100% (mostly in interrupt time) and seems to be able to keep
> that up forever. Which reminds me I need to see if I can work out a patch to
> enable interrupt mitigation for that chip. :)
> I've just started migrating to 6-stable so I might give it a try sometime
> soon. I need to clone the current 5.x install first just in case its flaky. I
> did the same going from 4 to 5.
I was out of town for several days with no computer, so I haven't been able to
work on this for a bit. I'm back on the case, now.
I think you'll be fine on 6-stable. The red-black tree code was added after the
netbsd-6 branch, and since I believe that's where the problem lies, I don't
think anyone other than -current users will see the problem.
Prior to IPF 5.x, a simple hash table was used, and the locking in ip_state.c
was appropriate for that data structure. I think it needs to be reworked a
little, now. This will add a new point of contention, since now the entire rb
tree must be locked, but it seems to be updated fairly rarely, so I don't think
this will be a noticeable performance hit.
I had only a few minutes to work on this before I left. I tried added a new
lock protecting the entire rb tree, but that didn't seem to be enough. I'll see
what I can manage today.
Main Index |
Thread Index |