[bind10-dev] Thinking aloud: Multi-CPU auth

[Jerry Scharf]

I hope these comments are of use.

There have been discussions whether functionality x is available on an 
o/s for doing things one way vs. another. I would suggest that the 
modular nature of BIND 10 was designed to deal with exactly this situation.

We have two very different audiences for auth/recursive servers. One is 
the high performance, high feature audience. The other is the run it on 
anything and fit it into a wireless router audience.

I think we want to view these as separate audiences with potentially 
separate decisions about code design. It also allows you to concentrate 
on one of the two for now, just knowing that the other is waiting down 
the road. This allows the multicore design to use the best features 
available and design for the constraints of that environment.

My personal experience is that shared memory becomes almost mandatory 
when trying to have many accessors against the same data. It would seem 
that you might  want to go to a multiple reader, single updater model as 
well. (Auth asking the datastore fronting cache or recursive asking the 
primary cache.)

I also do not consider a 2, 4 or even 8 core system to be that large. To 
satisfy the needs of an ISP for recursive or a registry for auth 
services, we are talking more like 16-24 cores today, more in the 
future. If the system has good scaling, this could extend even farther 
over time (48 cores is the top right now in a simple server.) I would 
personally recommend that there be a 24 core system (2x12 core opteron 
or 3x8core xeon) be acquired for testing. Cache control and memory 
bandwidth becomes a critical issues at these levels.

jerry s