1. 20 Jul, 2018 1 commit
    • Benedict Wong's avatar
      xfrm: Remove xfrmi interface ID from flowi · bc56b334
      Benedict Wong authored
      In order to remove performance impact of having the extra u32 in every
      single flowi, this change removes the flowi_xfrm struct, prefering to
      take the if_id as a method parameter where needed.
      
      In the inbound direction, if_id is only needed during the
      __xfrm_check_policy() function, and the if_id can be determined at that
      point based on the skb. As such, xfrmi_decode_session() is only called
      with the skb in __xfrm_check_policy().
      
      In the outbound direction, the only place where if_id is needed is the
      xfrm_lookup() call in xfrmi_xmit2(). With this change, the if_id is
      directly passed into the xfrm_lookup_with_ifid() call. All existing
      callers can still call xfrm_lookup(), which uses a default if_id of 0.
      
      This change does not change any behavior of XFRMIs except for improving
      overall system performance via flowi size reduction.
      
      This change has been tested against the Android Kernel Networking Tests:
      
      https://android.googlesource.com/kernel/tests/+/master/net/testSigned-off-by: default avatarBenedict Wong <benedictwong@google.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      bc56b334
  2. 19 Jul, 2018 1 commit
  3. 11 Jul, 2018 2 commits
    • Arnd Bergmann's avatar
      ipv6: xfrm: use 64-bit timestamps · 03dc7a35
      Arnd Bergmann authored
      get_seconds() is deprecated because it can overflow on 32-bit
      architectures.  For the xfrm_state->lastused member, we treat the data
      as a 64-bit number already, so we just need to use the right accessor
      that works on both 32-bit and 64-bit machines.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      03dc7a35
    • Arnd Bergmann's avatar
      xfrm: use time64_t for in-kernel timestamps · 386c5680
      Arnd Bergmann authored
      The lifetime managment uses '__u64' timestamps on the user space
      interface, but 'unsigned long' for reading the current time in the kernel
      with get_seconds().
      
      While this is probably safe beyond y2038, it will still overflow in 2106,
      and the get_seconds() call is deprecated because fo that.
      
      This changes the xfrm time handling to use time64_t consistently, along
      with reading the time using the safer ktime_get_real_seconds(). It still
      suffers from problems that can happen from a concurrent settimeofday()
      call or (to a lesser degree) a leap second update, but since the time
      stamps are part of the user API, there is nothing we can do to prevent
      that.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      386c5680
  4. 01 Jul, 2018 1 commit
    • Nathan Harold's avatar
      xfrm: Allow Set Mark to be Updated Using UPDSA · 6d8e85ff
      Nathan Harold authored
      Allow UPDSA to change "set mark" to permit
      policy separation of packet routing decisions from
      SA keying in systems that use mark-based routing.
      
      The set mark, used as a routing and firewall mark
      for outbound packets, is made update-able which
      allows routing decisions to be handled independently
      of keying/SA creation. To maintain consistency with
      other optional attributes, the set mark is only
      updated if sent with a non-zero value.
      
      The per-SA lock and the xfrm_state_lock are taken in
      that order to avoid a deadlock with
      xfrm_timer_handler(), which also takes the locks in
      that order.
      Signed-off-by: default avatarNathan Harold <nharold@google.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      6d8e85ff
  5. 25 Jun, 2018 1 commit
    • Florian Westphal's avatar
      xfrm: policy: remove pcpu policy cache · e4db5b61
      Florian Westphal authored
      Kristian Evensen says:
        In a project I am involved in, we are running ipsec (Strongswan) on
        different mt7621-based routers. Each router is configured as an
        initiator and has around ~30 tunnels to different responders (running
        on misc. devices). Before the flow cache was removed (kernel 4.9), we
        got a combined throughput of around 70Mbit/s for all tunnels on one
        router. However, we recently switched to kernel 4.14 (4.14.48), and
        the total throughput is somewhere around 57Mbit/s (best-case). I.e., a
        drop of around 20%. Reverting the flow cache removal restores, as
        expected, performance levels to that of kernel 4.9.
      
      When pcpu xdst exists, it has to be validated first before it can be
      used.
      
      A negative hit thus increases cost vs. no-cache.
      
      As number of tunnels increases, hit rate decreases so this pcpu caching
      isn't a viable strategy.
      
      Furthermore, the xdst cache also needs to run with BH off, so when
      removing this the bh disable/enable pairs can be removed too.
      
      Kristian tested a 4.14.y backport of this change and reported
      increased performance:
      
        In our tests, the throughput reduction has been reduced from around -20%
        to -5%. We also see that the overall throughput is independent of the
        number of tunnels, while before the throughput was reduced as the number
        of tunnels increased.
      Reported-by: default avatarKristian Evensen <kristian.evensen@gmail.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      e4db5b61
  6. 23 Jun, 2018 25 commits
  7. 22 Jun, 2018 9 commits