netdev - Re: [PATCH 0/16] Metrics restructuring.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1341934510.3265.5521.camel@edumazet-glaptop>
Date:	Tue, 10 Jul 2012 17:35:10 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH 0/16] Metrics restructuring.

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@...emloft.net>

This looks great !


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