Re: IPFilter issue in -current

[Geoff Adams <gadams+netbsd%avernus.com@localhost>]

On Nov 28, 2012, at 1:57 PM, Mike Pumford 
<mpumford%black-star.demon.co.uk@localhost> wrote:

> 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.

- Geoff