Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > > + > > + /* pointer to array of counters, one per CPU > > + * each rule maps 1:1 to an entry in the percpu counter array. > > + */ > > + struct xt_counters **counters; > > + > > You could avoid using this array, if you use alloc_percpu(struct > xt_counter) per counter. I used this since it fits with the jumpstack allocation that we already have. Is there an inherent advantage to alloc_percpu? [ I'm asking to see if it makes sense to convert jump stack too ]. > In the rules, instead of storing the index of each counter, store the > percpu address. -v How? What address? You mean relative offset to counter start? > This would avoid yet another indirection in iptables. I don't see how I can avoid it. when rule x matches, I need to increment the corresponding counter for that rule. But there is no 1:1 mapping of addresses, and I found no way to infer the correct counter address to use for the rule just by looking at ipt_entry address. Thats why the entry stores the 'counter' index: to find the counter to increment based on current cpu counter array and the rule number. > And it would be nice avoiding this stuff on non SMP kernels maybe ? Hmm. Will have to think about this to minimize ifdef kludgery. But, yes, I agree. Will fix it in v3. Thanks Eric. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
