1. 11 6月, 2014 1 次提交
  2. 05 6月, 2014 8 次提交
  3. 03 6月, 2014 3 次提交
    • Y
      tcp: fix cwnd undo on DSACK in F-RTO · 0cfa5c07
      Yuchung Cheng 提交于
      This bug is discovered by an recent F-RTO issue on tcpm list
      https://www.ietf.org/mail-archive/web/tcpm/current/msg08794.html
      
      The bug is that currently F-RTO does not use DSACK to undo cwnd in
      certain cases: upon receiving an ACK after the RTO retransmission in
      F-RTO, and the ACK has DSACK indicating the retransmission is spurious,
      the sender only calls tcp_try_undo_loss() if some never retransmisted
      data is sacked (FLAG_ORIG_DATA_SACKED).
      
      The correct behavior is to unconditionally call tcp_try_undo_loss so
      the DSACK information is used properly to undo the cwnd reduction.
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0cfa5c07
    • D
      fib_trie: use seq_file_net rather than seq->private · 30f38d2f
      David Ahern 提交于
      Make fib_triestat_seq_show consistent with other /proc/net files and
      use seq_file_net.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: James Morris <jmorris@namei.org>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30f38d2f
    • E
      inetpeer: get rid of ip_id_count · 73f156a6
      Eric Dumazet 提交于
      Ideally, we would need to generate IP ID using a per destination IP
      generator.
      
      linux kernels used inet_peer cache for this purpose, but this had a huge
      cost on servers disabling MTU discovery.
      
      1) each inet_peer struct consumes 192 bytes
      
      2) inetpeer cache uses a binary tree of inet_peer structs,
         with a nominal size of ~66000 elements under load.
      
      3) lookups in this tree are hitting a lot of cache lines, as tree depth
         is about 20.
      
      4) If server deals with many tcp flows, we have a high probability of
         not finding the inet_peer, allocating a fresh one, inserting it in
         the tree with same initial ip_id_count, (cf secure_ip_id())
      
      5) We garbage collect inet_peer aggressively.
      
      IP ID generation do not have to be 'perfect'
      
      Goal is trying to avoid duplicates in a short period of time,
      so that reassembly units have a chance to complete reassembly of
      fragments belonging to one message before receiving other fragments
      with a recycled ID.
      
      We simply use an array of generators, and a Jenkin hash using the dst IP
      as a key.
      
      ipv6_select_ident() is put back into net/ipv6/ip6_output.c where it
      belongs (it is only used from this file)
      
      secure_ip_id() and secure_ipv6_id() no longer are needed.
      
      Rename ip_select_ident_more() to ip_select_ident_segs() to avoid
      unnecessary decrement/increment of the number of segments.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73f156a6
  4. 31 5月, 2014 1 次提交
  5. 24 5月, 2014 3 次提交
  6. 23 5月, 2014 2 次提交
    • L
      ipv4: initialise the itag variable in __mkroute_input · fbdc0ad0
      Li RongQing 提交于
      the value of itag is a random value from stack, and may not be initiated by
      fib_validate_source, which called fib_combine_itag if CONFIG_IP_ROUTE_CLASSID
      is not set
      
      This will make the cached dst uncertainty
      Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbdc0ad0
    • N
      tcp: make cwnd-limited checks measurement-based, and gentler · ca8a2263
      Neal Cardwell 提交于
      Experience with the recent e114a710 ("tcp: fix cwnd limited
      checking to improve congestion control") has shown that there are
      common cases where that commit can cause cwnd to be much larger than
      necessary. This leads to TSO autosizing cooking skbs that are too
      large, among other things.
      
      The main problems seemed to be:
      
      (1) That commit attempted to predict the future behavior of the
      connection by looking at the write queue (if TSO or TSQ limit
      sending). That prediction sometimes overestimated future outstanding
      packets.
      
      (2) That commit always allowed cwnd to grow to twice the number of
      outstanding packets (even in congestion avoidance, where this is not
      needed).
      
      This commit improves both of these, by:
      
      (1) Switching to a measurement-based approach where we explicitly
      track the largest number of packets in flight during the past window
      ("max_packets_out"), and remember whether we were cwnd-limited at the
      moment we finished sending that flight.
      
      (2) Only allowing cwnd to grow to twice the number of outstanding
      packets ("max_packets_out") in slow start. In congestion avoidance
      mode we now only allow cwnd to grow if it was fully utilized.
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ca8a2263
  7. 22 5月, 2014 1 次提交
  8. 21 5月, 2014 1 次提交
  9. 19 5月, 2014 1 次提交
  10. 17 5月, 2014 2 次提交
    • T
      ipv4: ip_tunnels: disable cache for nbma gre tunnels · 22fb22ea
      Timo Teräs 提交于
      The connected check fails to check for ip_gre nbma mode tunnels
      properly. ip_gre creates temporary tnl_params with daddr specified
      to pass-in the actual target on per-packet basis from neighbor
      layer. Detect these tunnels by inspecting the actual tunnel
      configuration.
      
      Minimal test case:
       ip route add 192.168.1.1/32 via 10.0.0.1
       ip route add 192.168.1.2/32 via 10.0.0.2
       ip tunnel add nbma0 mode gre key 1 tos c0
       ip addr add 172.17.0.0/16 dev nbma0
       ip link set nbma0 up
       ip neigh add 172.17.0.1 lladdr 192.168.1.1 dev nbma0
       ip neigh add 172.17.0.2 lladdr 192.168.1.2 dev nbma0
       ping 172.17.0.1
       ping 172.17.0.2
      
      The second ping should be going to 192.168.1.2 and head 10.0.0.2;
      but cached gre tunnel level route is used and it's actually going
      to 192.168.1.1 via 10.0.0.1.
      
      The lladdr's need to go to separate dst for the bug to trigger.
      Test case uses separate route entries, but this can also happen
      when the route entry is same: if there is a nexthop exception or
      the GRE tunnel is IPsec'ed in which case the dst points to xfrm
      bundle unique to the gre lladdr.
      
      Fixes: 7d442fab ("ipv4: Cache dst in tunnels")
      Signed-off-by: NTimo Teräs <timo.teras@iki.fi>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22fb22ea
    • D
      ip_tunnel: don't add tunnel twice · ee30ef4d
      Duan Jiong 提交于
      When using command "ip tunnel add" to add a tunnel, the tunnel will be added twice,
      through ip_tunnel_create() and ip_tunnel_update().
      
      Because the second is unnecessary, so we can just break after adding tunnel
      through ip_tunnel_create().
      Signed-off-by: NDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee30ef4d
  11. 16 5月, 2014 1 次提交
  12. 15 5月, 2014 2 次提交
  13. 14 5月, 2014 8 次提交
  14. 13 5月, 2014 1 次提交
  15. 12 5月, 2014 1 次提交
  16. 09 5月, 2014 4 次提交