1. 11 Jul, 2012 36 commits
  2. 10 Jul, 2012 4 commits
    • David S. Miller's avatar
      Merge branch 'metrics_restructure' · fdd28d73
      David S. Miller authored
      
      
      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: default avatarDavid S. Miller <davem@davemloft.net>
      fdd28d73
    • David S. Miller's avatar
      ipv4: Remove inetpeer from routes. · f185071d
      David S. Miller authored
      
      
      No longer used.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f185071d
    • David S. Miller's avatar
      ipv4: Calling ->cow_metrics() now is a bug. · 31248731
      David S. Miller authored
      
      
      Nothing every writes to ipv4 metrics any longer.
      
      PMTU is stored in rt->rt_pmtu.
      
      Dynamic TCP metrics are stored in a special TCP metrics cache,
      completely outside of the routes.
      
      Therefore ->cow_metrics() can simply nothing more than a WARN_ON
      trigger so we can catch anyone who tries to add new writes to
      ipv4 route metrics.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31248731
    • David S. Miller's avatar
      ipv4: Kill dst_copy_metrics() call from ipv4_blackhole_route(). · 2db2d67e
      David S. Miller authored
      
      
      Blackhole routes have a COW metrics operation that returns NULL
      always, therefore this dst_copy_metrics() call did absolutely
      nothing.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2db2d67e