[v3] fib_rules: add .suppress operation

This change adds a new operation to the fib_rules_ops struct; it allows the
suppression of routing decisions if certain criteria are not met by its
results.

The first implemented constraint is a minimum prefix length added to the
structures of routing rules. If a rule is added with a minimum prefix length
>0, only routes meeting this threshold will be considered. Any other (more
general) routing table entries will be ignored.

When configuring a system with multiple network uplinks and default routes, it
is often convinient to reference the main routing table multiple times - but
omitting the default route. Using this patch and a modified "ip" utility, this
can be achieved by using the following command sequence:

  $ ip route add table secuplink default via 10.42.23.1

  $ ip rule add pref 100            table main prefixlength 1
  $ ip rule add pref 150 fwmark 0xA table secuplink

With this setup, packets marked 0xA will be processed by the additional routing
table "secuplink", but only if no suitable route in the main routing table can
be found. By using a minimal prefixlength of 1, the default route (/0) of the
table "main" is hidden to packets processed by rule 100; packets traveling to
destinations with more specific routing entries are processed as usual.

Signed-off-by: Stefan Tomanek <stefan.tomanek@wertarbyte.de>
---
 include/net/fib_rules.h        |    4 ++++
 include/uapi/linux/fib_rules.h |    2 +-
 net/core/fib_rules.c           |    9 +++++++++
 net/ipv4/fib_rules.c           |   15 +++++++++++++++
 net/ipv6/fib6_rules.c          |   13 +++++++++++++
 5 files changed, 42 insertions(+), 1 deletion(-)

From: Stefan Tomanek <stefan.tomanek@wertarbyte.de>
Date: Tue, 30 Jul 2013 09:46:36 +0200

> This change adds a new operation to the fib_rules_ops struct; it allows the
> suppression of routing decisions if certain criteria are not met by its
> results.
> 
> The first implemented constraint is a minimum prefix length added to the
> structures of routing rules. If a rule is added with a minimum prefix length
>>0, only routes meeting this threshold will be considered. Any other (more
> general) routing table entries will be ignored.
> 
> When configuring a system with multiple network uplinks and default routes, it
> is often convinient to reference the main routing table multiple times - but
> omitting the default route. Using this patch and a modified "ip" utility, this
> can be achieved by using the following command sequence:
> 
>   $ ip route add table secuplink default via 10.42.23.1
> 
>   $ ip rule add pref 100            table main prefixlength 1
>   $ ip rule add pref 150 fwmark 0xA table secuplink
> 
> With this setup, packets marked 0xA will be processed by the additional routing
> table "secuplink", but only if no suitable route in the main routing table can
> be found. By using a minimal prefixlength of 1, the default route (/0) of the
> table "main" is hidden to packets processed by rule 100; packets traveling to
> destinations with more specific routing entries are processed as usual.
> 
> Signed-off-by: Stefan Tomanek <stefan.tomanek@wertarbyte.de>

I just want to mention that the more quirky crap we put into the FIB
rules layer, the harder it will every be to make a scalable data
structure for FIB rule handling.

Right now it's basically a linear walk of rules, with processing at
each level.

And every single ipv4 route lookup is going to go through this entire
process.

Anyways, there are coding style problems in your change which you'll
need to address:

> +		if (!err && ops->suppress && ops->suppress(rule, arg)) {
> +			continue;
> +		}

Since statement basic blocks should not use curly braces.

> +		if (!(arg->flags & FIB_LOOKUP_NOREF)) {
> +			fib_info_put(result->fi);
> +		}

Likewise.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dies schrieb David Miller (davem@davemloft.net):

> I just want to mention that the more quirky crap we put into the FIB
> rules layer, the harder it will every be to make a scalable data
> structure for FIB rule handling.
> 
> Right now it's basically a linear walk of rules, with processing at
> each level.

And it still is: but instead of just having pre-conditions whether to
consult a table, the patch introduces post-conditions that can reject
a routing decision retrieved from it.

> Anyways, there are coding style problems in your change which you'll
> need to address:

Fixed in latest patch, thanks for the hints.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Stefan Tomanek <stefan.tomanek@wertarbyte.de>
Date: Thu, 1 Aug 2013 02:24:07 +0200

> Dies schrieb David Miller (davem@davemloft.net):
> 
>> I just want to mention that the more quirky crap we put into the FIB
>> rules layer, the harder it will every be to make a scalable data
>> structure for FIB rule handling.
>> 
>> Right now it's basically a linear walk of rules, with processing at
>> each level.
> 
> And it still is: but instead of just having pre-conditions whether to
> consult a table, the patch introduces post-conditions that can reject
> a routing decision retrieved from it.

This doesn't change my argument at all.  The fact remains that the
more complex conditions we add to the fib rule lookup, the harder it
will be to optimize fib rule lookups into an O(1) or O(log n)
operation.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html