Re: priv_data patch

[Patrick McHardy <kaber@trash.net>]

Massimiliano Hofer wrote:
> On Monday 14 August 2006 3:34 pm, you wrote:
> 
>>[...]
>
> I'm afraid you are right. This limits the usefulness to volatile data that can 
> safely be discarded. This can be some sort of disposable statistic or 
> performance enhancing cache of data that can be retrieved in other ways.

Agreed.

> Without this patch we are condemned to ugly tricks for data needed by 
> condition, hashlimit and recent. I think this is useful, but I'll leave it to 
> you to decide if it's worth.

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?

> Any idea for a better userspace interface?
> It's not the first time you tell me that we could have a better "next 
> generation" userspace interface. Maybe it's time to start planning.
> Does anyone have wishes for new or different ways to do things?


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.

> Just an example without proper thought or planning: we could set an optional 
> way rules could use to tag themselves and have their data back if they want 
> it. As with priv_data this won't benefit everyone. I'll keep thinking of 
> better ways.


We want to get rid of the atomic table replacements entirely.

> IMHO a portion of data outside the one passed by userspace (persistent or 
> volatile) is a must in the long run and will free us from an arbitrary 
> constraint between userspace and kernelspace. I see other people are writing 
> matches that rely on separate user input to complete its data (interface 
> groups?) and they will need somewhere to store it.


Once we stop replacing entire rulesets and move to a finer grained level
this problem will be gone, state will be kept for all rules except the
ones affected. Using netlink attributes will also allow us to flexibly
enhance the interface as needed.