Optimization #426
Updated by Victor Julien about 12 years ago
In recent changes most of the thresholding code moved away from one big lock for the entire thresholding table. With the introduction of a host table, the thresholding that tracks per src or dst is now done in a fine grained manner, reducing lock contention. For thresholding tracked per rule however, we still use one big evil lock. So we need to fix that. Currently the data structure for storing these threshold entries is an array, with a size of the number of signatures. The signatures internal id (s->num) is the index. The array is stored in the de_ctx. We need to move away from this. As we are going to support rule reloads, the internal id can no longer be used here. The thresholding table should survive the rule reload. The signatures internal id's will change on a reload so they can't be used as index. So ideally we'd have some form of hash that uses the gid+sid to lookup the thresholding data struct without a global lock. Options would be: would: - have a hash with per row locking and update threshold entry under row lock. - have a hash with per row locking for lookups and a per threshold entry lock for checks and updates (this is how flow and host tables work). - make sure internal id's for sigs remain the same with reloads, using unique id's for new sigs -- too complicated I think. Other options?