netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ville Nuorvala <vnuorval@tcs.hut.fi>
To: Thomas Graf <tgraf@suug.ch>
Cc: netdev@vger.kernel.org, usagi-core@linux-ipv6.org,
	yoshfuji@linux-ipv6.org, davem@davemloft.net, anttit@tcs.hut.fi
Subject: Re: [PATCH 2/5] [IPV6]: Multiple Routing Tables
Date: Mon, 31 Jul 2006 16:55:50 +0300	[thread overview]
Message-ID: <44CE0BE6.1070108@tcs.hut.fi> (raw)
In-Reply-To: <20060726221849.495778268@postel.suug.ch>

Thomas Graf wrote:

> Adds the framework to support multiple IPv6 routing tables.
> Currently all automatically generated routes are put into the
> same table. This could be changed at a later point after
> considering the produced locking overhead.

Hi Thomes, some minor comments below.

> When locating routes for redirects only the main table is
> searched for now. Since policy rules will not be reversible
> it is unclear whether it makes sense to change this.

This is a good point. You are absolutely correct about the policy rules.

IIRC, I initially looked through all the tables, but skipped this
behavior when I rewrote the code for 2.6.11. Currently I'm once again
in favor of looping through them all. This is IMO at least closer to the
spirit of RFC 2461 section 8.3. where a host SHOULD update its
destination cache upon receiving a redirect. If we don't look through
all tables, we can't ensure this happens.

> Index: net-2.6.git/include/net/ip6_fib.h
> ===================================================================
> --- net-2.6.git.orig/include/net/ip6_fib.h
> +++ net-2.6.git/include/net/ip6_fib.h

<snip>

> @@ -143,12 +146,41 @@ struct rt6_statistics {
>  
>  typedef void			(*f_pnode)(struct fib6_node *fn, void *);
>  
> -extern struct fib6_node		ip6_routing_table;
> +struct fib6_table {
> +	struct hlist_node	tb6_hlist;
> +	u32			tb6_id;
> +	rwlock_t		tb6_lock;
> +	struct fib6_node	tb6_root;
> +};
> +
> +#define RT6_TABLE_UNSPEC	RT_TABLE_UNSPEC
> +#define RT6_TABLE_MAIN		RT_TABLE_MAIN
> +#define RT6_TABLE_LOCAL		RT6_TABLE_MAIN
> +#define RT6_TABLE_DFLT		RT6_TABLE_MAIN
> +#define RT6_TABLE_INFO		RT6_TABLE_MAIN

IMO it's a bit inconsistent to define a separate table entry for Route
Information generated routes, but not Prefix Information based ones.
What do you say about adding a RT6_TABLE_PRFX?

> Index: net-2.6.git/net/ipv6/route.c
> ===================================================================
> --- net-2.6.git.orig/net/ipv6/route.c
> +++ net-2.6.git/net/ipv6/route.c

<snip>

> @@ -1435,12 +1523,15 @@ static struct rt6_info *rt6_add_route_in
>  struct rt6_info *rt6_get_dflt_router(struct in6_addr *addr, struct net_device *dev)
>  {	
>  	struct rt6_info *rt;
> -	struct fib6_node *fn;
> +	struct fib6_table *table;
>  
> -	fn = &ip6_routing_table;
> +	/* TODO: It might be better to search all tables */
> +	table = fib6_get_table(RT6_TABLE_DFLT);

As long as the table for default routes is RT6_TABLE_DFLT and can't be
configured by the user, I think the correct behavior is just to search
RT6_TABLE_DFLT.

Otherwise it looks very good!

Regards,
Ville

  parent reply	other threads:[~2006-07-31 13:55 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-26 22:11 [RFC] Multiple IPV6 Routing Tables & Policy Routing Thomas Graf
2006-07-26 22:00 ` [PATCH 1/5] [IPV6]: Remove ndiscs rt6_lock dependency Thomas Graf
2006-07-26 22:28   ` David Miller
2006-07-26 23:34     ` Tushar Gohad
2006-07-26 23:34       ` David Miller
2006-07-31 11:01     ` Ville Nuorvala
2006-07-26 22:00 ` [PATCH 2/5] [IPV6]: Multiple Routing Tables Thomas Graf
2006-07-26 22:39   ` David Miller
2006-07-26 22:48     ` Thomas Graf
2006-07-26 22:55       ` David Miller
2006-07-29  4:13   ` YOSHIFUJI Hideaki / 吉藤英明
2006-07-29  4:14     ` David Miller
2006-07-29  4:28       ` YOSHIFUJI Hideaki / 吉藤英明
2006-07-29 10:29     ` Thomas Graf
2006-07-31 13:55   ` Ville Nuorvala [this message]
2006-07-31 14:01     ` Herbert Xu
2006-07-31 14:02       ` Herbert Xu
2006-07-31 15:41       ` Thomas Graf
2006-07-31 20:09         ` David Miller
2006-07-31 15:34     ` Thomas Graf
2006-07-26 22:00 ` [PATCH 3/5] [NET]: Protocol Independant Policy Routing Rules Framework Thomas Graf
2006-07-26 22:41   ` David Miller
2006-07-27  5:58   ` James Morris
2006-07-27  6:02     ` David Miller
2006-07-27 22:39       ` [RESEND " Thomas Graf
2006-07-27 22:58         ` Patrick McHardy
2006-07-27 23:17           ` David Miller
2006-07-27 23:31             ` Patrick McHardy
2006-07-28  9:25           ` Martin Josefsson
2006-07-29  1:40             ` Patrick McHardy
2006-07-29  7:25               ` Martin Josefsson
2006-07-27 23:30         ` Patrick McHardy
2006-07-28 10:23           ` Thomas Graf
2006-07-31 14:46         ` Ville Nuorvala
2006-07-31 15:24           ` Thomas Graf
2006-07-31 18:01             ` Patrick McHardy
2006-07-31 20:01               ` Thomas Graf
2006-07-26 22:00 ` [PATCH 4/5] [IPV6]: Policy Routing Rules Thomas Graf
2006-07-26 22:42   ` David Miller
2006-07-26 23:26   ` David Miller
2006-07-26 23:33   ` David Miller
2006-07-26 23:40     ` David Miller
2006-07-27 22:40       ` [RESEND " Thomas Graf
2006-07-31 14:55         ` Ville Nuorvala
2006-07-26 22:00 ` [PATCH 5/5] [IPV4]: Use Protocol Independant Policy Routing Rules Framework Thomas Graf
2006-07-26 22:43   ` David Miller
2006-07-26 23:47   ` David Miller
2006-07-27 22:40     ` [RESEND " Thomas Graf
2006-07-28  6:10 ` [RFC] Multiple IPV6 Routing Tables & Policy Routing YOSHIFUJI Hideaki / 吉藤英明
2006-07-28  8:23   ` David Miller
2006-07-28 10:32   ` Thomas Graf
2006-07-29  4:27     ` YOSHIFUJI Hideaki / 吉藤英明
2006-07-31 11:01 ` Ville Nuorvala
  -- strict thread matches above, loose matches on Subject: below --
2006-08-04 10:23 [PATCHSET] " Thomas Graf
2006-08-03 22:00 ` [PATCH 2/5] [IPV6]: Multiple Routing Tables Thomas Graf
2006-08-05  9:00   ` Patrick McHardy
2006-08-05  9:21     ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44CE0BE6.1070108@tcs.hut.fi \
    --to=vnuorval@tcs.hut.fi \
    --cc=anttit@tcs.hut.fi \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    --cc=usagi-core@linux-ipv6.org \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).