Re: [PATCH RFC net-next 1/4] ipv4: fib_rules: support match on sport, dport and ip proto
On 02/12/2018 04:03 PM, David Miller wrote: From: Eric Dumazet Date: Mon, 12 Feb 2018 13:54:59 -0800 We had project/teams using different routing tables for each vlan they setup :/ Indeed, people use FIB rules and think they can scale in software. As currently implemented, they can't. The example you give sounds possibly like a great VRF use case btw :-) I'm one of those people with lots of FIB rules wishing it would scale better, and wanting a routing table per netdev. If there is a relatively easy suggestion to make this work better, I'd like to give it a try. I have not looked at VRF at all to date... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [PATCH RFC net-next 1/4] ipv4: fib_rules: support match on sport, dport and ip proto
On Tue, Feb 13, 2018 at 8:34 AM, David Miller wrote: > From: Roopa Prabhu > Date: Tue, 13 Feb 2018 08:19:35 -0800 > >> - Regardless of this series, I think we should optimize ip rules or >> have a new implementation of policy based routing. happy to hear about >> possible options here: >> - optimize the existing implementation (have there been >> previous discussions on possible options ?) >> - @netdev2.2, I did outline a possible option for tc to >> provide an l3 hook for policy based routing (people were ok with this >> and I was told more tc hooks were in the works). >> tc was a choice mainly because of all its existing match >> options (flower for example). Will that help ? >> - We should have an ebpf accelerated implementation >> regardless for people to use it if they want to scale rules > > The problem is that arbitrary prefixing in the rules. That prevents > O(1) algorithms from being used to maintain the table. > > If they were all just non-prefixed keys we could do a hash table or > similar. ah, got it. > > I guess we could do a trie (on saddr) to a (on daddr) trie (like the > ipv6 subtrees do), but that's a lot of complexity just for fib rules. > agreed.
Re: [PATCH RFC net-next 1/4] ipv4: fib_rules: support match on sport, dport and ip proto
From: Roopa Prabhu Date: Tue, 13 Feb 2018 08:19:35 -0800 > - Regardless of this series, I think we should optimize ip rules or > have a new implementation of policy based routing. happy to hear about > possible options here: > - optimize the existing implementation (have there been > previous discussions on possible options ?) > - @netdev2.2, I did outline a possible option for tc to > provide an l3 hook for policy based routing (people were ok with this > and I was told more tc hooks were in the works). > tc was a choice mainly because of all its existing match > options (flower for example). Will that help ? > - We should have an ebpf accelerated implementation > regardless for people to use it if they want to scale rules The problem is that arbitrary prefixing in the rules. That prevents O(1) algorithms from being used to maintain the table. If they were all just non-prefixed keys we could do a hash table or similar. I guess we could do a trie (on saddr) to a (on daddr) trie (like the ipv6 subtrees do), but that's a lot of complexity just for fib rules.
Re: [PATCH RFC net-next 1/4] ipv4: fib_rules: support match on sport, dport and ip proto
On Mon, Feb 12, 2018 at 4:03 PM, David Miller wrote: > From: Eric Dumazet > Date: Mon, 12 Feb 2018 13:54:59 -0800 > >> We had project/teams using different routing tables for each vlan they >> setup :/ > > Indeed, people use FIB rules and think they can scale in software. As > currently implemented, they can't. > > The example you give sounds possibly like a great VRF use case btw :-) thanks for all the feedback so far. replying to all the discussions on this thread so far here :): - like davidA mentioned, we will be hardware offloading this. And the most common hw offload case requires a 5-tuple match - This series just extends the existing match options for people to use the existing api if they choose too (with a performance penalty) - the main problem was telling people ...'oh, u cannot use ip rules just because it does not support match on sport and so on and there is no other way to do policy based routing on Linux' - Regardless of this series, I think we should optimize ip rules or have a new implementation of policy based routing. happy to hear about possible options here: - optimize the existing implementation (have there been previous discussions on possible options ?) - @netdev2.2, I did outline a possible option for tc to provide an l3 hook for policy based routing (people were ok with this and I was told more tc hooks were in the works). tc was a choice mainly because of all its existing match options (flower for example). Will that help ? - We should have an ebpf accelerated implementation regardless for people to use it if they want to scale rules
Re: [PATCH RFC net-next 1/4] ipv4: fib_rules: support match on sport, dport and ip proto
From: Eric Dumazet Date: Mon, 12 Feb 2018 13:54:59 -0800 > We had project/teams using different routing tables for each vlan they > setup :/ Indeed, people use FIB rules and think they can scale in software. As currently implemented, they can't. The example you give sounds possibly like a great VRF use case btw :-)
Re: [PATCH RFC net-next 1/4] ipv4: fib_rules: support match on sport, dport and ip proto
On 2/12/18 2:54 PM, Eric Dumazet wrote: > On Mon, 2018-02-12 at 16:05 -0500, David Miller wrote: >> From: Eric Dumazet >> Date: Mon, 12 Feb 2018 12:49:33 -0800 >> >>> Any setup with about 20 rules to be evaluated (per packet cost) will >>> feel the pain... >>> >>> I wonder if we could JIT/eBPF this thing. >> >> That's true for the software implementation angle. >> >> But I bet anyone actually using this thing will get it hardware >> offloaded. > > I wish :) > > We had project/teams using different routing tables for each vlan they > setup :/ VRF per VLAN, only 1 rule needed > > Setups with tunnels are doubly impacted, it is really easy to reach 20 > evaluated rules per incoming and outgoing packet. > >
Re: [PATCH RFC net-next 1/4] ipv4: fib_rules: support match on sport, dport and ip proto
On Mon, 2018-02-12 at 16:05 -0500, David Miller wrote: > From: Eric Dumazet > Date: Mon, 12 Feb 2018 12:49:33 -0800 > > > Any setup with about 20 rules to be evaluated (per packet cost) will > > feel the pain... > > > > I wonder if we could JIT/eBPF this thing. > > That's true for the software implementation angle. > > But I bet anyone actually using this thing will get it hardware > offloaded. I wish :) We had project/teams using different routing tables for each vlan they setup :/ Setups with tunnels are doubly impacted, it is really easy to reach 20 evaluated rules per incoming and outgoing packet.
Re: [PATCH RFC net-next 1/4] ipv4: fib_rules: support match on sport, dport and ip proto
On 2/12/18 2:05 PM, David Miller wrote: > From: Eric Dumazet > Date: Mon, 12 Feb 2018 12:49:33 -0800 > >> Any setup with about 20 rules to be evaluated (per packet cost) will >> feel the pain... >> >> I wonder if we could JIT/eBPF this thing. I had the same comments -- overhead and ebpf and rules, but ... > > That's true for the software implementation angle. > > But I bet anyone actually using this thing will get it hardware > offloaded. > what Dave said. ;-)
Re: [PATCH RFC net-next 1/4] ipv4: fib_rules: support match on sport, dport and ip proto
From: Eric Dumazet Date: Mon, 12 Feb 2018 12:49:33 -0800 > Any setup with about 20 rules to be evaluated (per packet cost) will > feel the pain... > > I wonder if we could JIT/eBPF this thing. That's true for the software implementation angle. But I bet anyone actually using this thing will get it hardware offloaded.
Re: [PATCH RFC net-next 1/4] ipv4: fib_rules: support match on sport, dport and ip proto
On Sun, 2018-02-11 at 14:26 -0800, Roopa Prabhu wrote:
> From: Roopa Prabhu
>
> Add support to match on src port, dst port and ip protocol.
>
> Signed-off-by: Roopa Prabhu
> ---
> include/uapi/linux/fib_rules.h | 3 +++
> net/ipv4/fib_rules.c | 46
> --
> 2 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/fib_rules.h b/include/uapi/linux/fib_rules.h
> index 2b642bf..79ff3c2 100644
> --- a/include/uapi/linux/fib_rules.h
> +++ b/include/uapi/linux/fib_rules.h
> @@ -58,6 +58,9 @@ enum {
> FRA_PAD,
> FRA_L3MDEV, /* iif or oif is l3mdev goto its table */
> FRA_UID_RANGE, /* UID range */
> + FRA_PROTO, /* ip proto */
> + FRA_SPORT, /* sport */
> + FRA_DPORT, /* dport */
> __FRA_MAX
> };
>
> diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
> index 35d646a..f204c85 100644
> --- a/net/ipv4/fib_rules.c
> +++ b/net/ipv4/fib_rules.c
> @@ -45,13 +45,17 @@ struct fib4_rule {
> #ifdef CONFIG_IP_ROUTE_CLASSID
> u32 tclassid;
> #endif
> + __be16 sport;
> + __be16 dport;
> + u8 proto;
> };
>
> static bool fib4_rule_matchall(const struct fib_rule *rule)
> {
> struct fib4_rule *r = container_of(rule, struct fib4_rule, common);
>
> - if (r->dst_len || r->src_len || r->tos)
> + if (r->dst_len || r->src_len || r->tos || r->proto || r->sport ||
> + r->dport)
> return false;
> return fib_rule_matchall(rule);
> }
> @@ -182,6 +186,15 @@ static int fib4_rule_match(struct fib_rule *rule, struct
> flowi *fl, int flags)
> if (r->tos && (r->tos != fl4->flowi4_tos))
> return 0;
>
> + if (r->proto && (r->proto != fl4->flowi4_proto))
> + return 0;
> +
> + if (r->sport && (r->sport != fl4->fl4_sport))
> + return 0;
> +
> + if (r->dport && (r->dport != fl4->fl4_dport))
> + return 0;
> +
Any setup with about 20 rules to be evaluated (per packet cost) will
feel the pain...
I wonder if we could JIT/eBPF this thing.
