[PATCH 0/16] Metrics restructuring.

[PATCH 0/16] Metrics restructuring.

[David Miller]

This patch series works towards the goal of minimizing the amount
of things that can change in an ipv4 route.

In a regime where the routing cache is removed, route changes will
lead to cloning in the FIB tables or similar.

The largest trigger of route metrics writes, TCP, now has it's own
cache of dynamic metric state.  The timewait timestamps are stored
there now as well.

As a result of that, pre-cowing metrics is no longer necessary,
and therefore FLOWI_FLAG_PRECOW_METRICS is removed.

Redirect and PMTU handling is moved back into the ipv4 routes.  I'm
sorry for all the headaches trying to do this in the inetpeer has
caused, it was the wrong approach for sure.

Since metrics become read-only for ipv4 we no longer need the inetpeer
hung off of the ipv4 routes either.  So those disappear too.

Also, timewait sockets no longer need to hold onto an inetpeer either.

After this series, we still have some details to resolve wrt. PMTU and
redirects for a route-cache-less system:

1) With just the plain route cache removal, PMTU will continue to
   work mostly fine.  This is because of how the local route users
   call down into the PMTU update code with the route they already
   hold.

   However, if we wish to cache pre-computed routes in fib_info
   nexthops (which we want for performance), then we need to add
   route cloning for PMTU events.

2) Redirects require more work.  First, redirects must be changed to
   be handled like PMTU.  Wherein we call down into the sockets and
   other entities, and then they call back into the routing code with
   the route they were using.

   So we'll be adding an ->update_nexthop() method alongside
   ->update_pmtu().

   And then, like for PMTU, we'll need cloning support once we start
   caching routes in the fib_info nexthops.

But that's it, we can completely pull the trigger and remove the
routing cache with minimal disruptions.

As it is, this patch series alone helps a lot of things.  For one,
routing cache entry creation should be a lot faster, because we no
longer do inetpeer lookups (even to check if an entry exists).

This patch series also opens the door for non-DST_HOST ipv4 routes,
because nothing fundamentally cares about rt->rt_dst any more.  It
can be removed with the base routing cache removal patch.  In fact,
that was the primary goal of this patch series.

Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [PATCH 0/16] Metrics restructuring.

[Eric Dumazet]

On Tue, 2012-07-10 at 08:07 -0700, David Miller wrote:
> This patch series works towards the goal of minimizing the amount
> of things that can change in an ipv4 route.
> 
> In a regime where the routing cache is removed, route changes will
> lead to cloning in the FIB tables or similar.
> 
> The largest trigger of route metrics writes, TCP, now has it's own
> cache of dynamic metric state.  The timewait timestamps are stored
> there now as well.
> 
> As a result of that, pre-cowing metrics is no longer necessary,
> and therefore FLOWI_FLAG_PRECOW_METRICS is removed.
> 
> Redirect and PMTU handling is moved back into the ipv4 routes.  I'm
> sorry for all the headaches trying to do this in the inetpeer has
> caused, it was the wrong approach for sure.
> 
> Since metrics become read-only for ipv4 we no longer need the inetpeer
> hung off of the ipv4 routes either.  So those disappear too.
> 
> Also, timewait sockets no longer need to hold onto an inetpeer either.
> 
> After this series, we still have some details to resolve wrt. PMTU and
> redirects for a route-cache-less system:
> 
> 1) With just the plain route cache removal, PMTU will continue to
>    work mostly fine.  This is because of how the local route users
>    call down into the PMTU update code with the route they already
>    hold.
> 
>    However, if we wish to cache pre-computed routes in fib_info
>    nexthops (which we want for performance), then we need to add
>    route cloning for PMTU events.
> 
> 2) Redirects require more work.  First, redirects must be changed to
>    be handled like PMTU.  Wherein we call down into the sockets and
>    other entities, and then they call back into the routing code with
>    the route they were using.
> 
>    So we'll be adding an ->update_nexthop() method alongside
>    ->update_pmtu().
> 
>    And then, like for PMTU, we'll need cloning support once we start
>    caching routes in the fib_info nexthops.
> 
> But that's it, we can completely pull the trigger and remove the
> routing cache with minimal disruptions.
> 
> As it is, this patch series alone helps a lot of things.  For one,
> routing cache entry creation should be a lot faster, because we no
> longer do inetpeer lookups (even to check if an entry exists).
> 
> This patch series also opens the door for non-DST_HOST ipv4 routes,
> because nothing fundamentally cares about rt->rt_dst any more.  It
> can be removed with the base routing cache removal patch.  In fact,
> that was the primary goal of this patch series.
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>

This looks great !

Re: [PATCH 0/16] Metrics restructuring.

[Joe Perches]

On Tue, 2012-07-10 at 08:07 -0700, David Miller wrote:
> This patch series works towards the goal of minimizing the amount
> of things that can change in an ipv4 route.

Good stuff.

I hope the good information below here will go into the
git log via a merge message too.

thanks, Joe

Re: [PATCH 0/16] Metrics restructuring.

[David Miller]

From: Joe Perches <joe@perches.com>
Date: Tue, 10 Jul 2012 09:11:34 -0700

> I hope the good information below here will go into the
> git log via a merge message too.

Is there some voodoo to force a merge commit in what
would otherwise be a fast-forward?

Re: [PATCH 0/16] Metrics restructuring.

[Christian Franke]

On 07/10/2012 06:18 PM, David Miller wrote:
> Is there some voodoo to force a merge commit in what
> would otherwise be a fast-forward?

git merge --no-ff

-Christian

Re: [PATCH 0/16] Metrics restructuring.

[David Miller]

Ok, I've incorporated all the feedback and pushed the result
into net-next:

1) Namespace support for TCP metrics cache.

2) Cleanup address comparisons and add necessary sparse casts.

3) Trailing whitespace.

Thanks everyone.