Re: new ABI

[Patrick McHardy <kaber@trash.net>]

Jozsef Kadlecsik wrote:
> What makes me uneasy is that we want to control the network traffic (do
> firewalling) over a protocol which is managed by the network core itself.
> Somehow it hurts compartmentalization.

I don't really worry about that.

>>Reliability is not hard to achieve on the userspace->kernel path if you
>>don't mind eating one RTT for each rule update (which is not very
>>large), just send the update and wait for an ACK or an error, then
>>handle it.
> 
> 
> And how should the error be handled? Re-send the same request immediately
> and thus hammering the system? Or should we use a linear/exponential
> backoff? :-)

That depends on the error. For an error indicating receive buffer
overflow (which can only happen with multiple concurrent senders
on the userspace->kernel path) you can usually try to retransmit
immediately. As long as messages are queued one of the other
senders will stay in the kernel working off the netlink queue
(without beeing able to add any messages during that time),
so it shouldn't last long. Alternatively you can simply use blocking
IO. In the end there's no difference to setsockopt, you have
a maximum throughput and once you've hit it you run into problems.

> What if it's a RESTORE operation and we are in the middle of
> adding thousands of rules to the kernel. Should we then implement
> transactions and all successfully added rules be removed in the case of a
> fatal failure? (Allowing multiple alternate tables can solve it of
> course.)

We could do that. Thats the price of a non-atomic interface (on
the ruleset level). And I think we've learned what the price of
an atomic one is :)

>>>Yes. And I'd add one more priciple:
>>>
>>>+ All parts must be designed to take into account rule- and
>>>  (match/target) state-replication between firewalls in active-active
>>>  setups.
>>
>>Agreed, that would be nice to have (and not very hard).
> 
> 
> + Match/target versioning support, i.e. be able to specify
>   version-dependent features. That might require OR operation
>   support at some level in one rule:
> 
> # Handle two versions of the same module:
> -m foo --foo-version 2 <flags 2> --OR --foo-version 1 <flags 1>
> # Handle new or possibly missing module
> -m bar --bar-version 1 <flags 1> --OR --false|true|fatal-error|ignore-rule

Thats more of a userspace thing. Modules will always have to be
backwards compatible, so if new attributes are not understood,
use the old ones if the user is fine with it.