Re: priv_data patch

[Patrick McHardy <kaber@trash.net>]

Massimiliano Hofer wrote:
> On Monday 14 August 2006 4:37 pm, you wrote:
> 
>>Hmm .. recent does a table lookup during runtime and the table could be
>>cached. That would improve things a bit, but in my opinion not enough
>>to justify this patch. Same for hashlimit. What data would condition
>>store exactly?
> 
> 
> I need a pointer to per condition data, so that multiple rules with the same 
> name refer to the same flag.
> I can break userspace compatibility and store a pointer in the userspace 
> structure. I just thought this could be useful to everyone (and let me 
> maintain userspace compatibility along the way).


That looks like the only valid type of usage. Which means your initial
implementation, which just provided space for a pointer to the
individual instances, might have been the better way. I need to think
about this some more and look at the modules that could make use of
this again.

>>Its actually quite clear what is needed. We want a userspace interface
>>built on netlink, that acts on individual rules, not entire rulesets.
>>There are a few more ideas, like handling negation centrally, allowing
>>userspace to specify whether a target is terminal or not, allow multiple
>>non-terminal targets in a row, etc, but nothing really fundamental.
> 
> 
> I thought the current way of doing things was specifically designed to 
> minimize softirq locking (especially with arbitarily long chains and 
> arbitrary initialization code). We could switch to RCU lists, though...


Yes, it should be possible to do lockless ruleset evaluation (at least
on the ruleset level, some modules will still need locking).