1. 27 1月, 2012 1 次提交
    • W
      ipv6: Fix ip_gre lockless xmits. · f2b3ee9e
      Willem de Bruijn 提交于
      Tunnel devices set NETIF_F_LLTX to bypass HARD_TX_LOCK.  Sit and
      ipip set this unconditionally in ops->setup, but gre enables it
      conditionally after parameter passing in ops->newlink. This is
      not called during tunnel setup as below, however, so GRE tunnels are
      still taking the lock.
      
      modprobe ip_gre
      ip tunnel add test0 mode gre remote 10.5.1.1 dev lo
      ip link set test0 up
      ip addr add 10.6.0.1 dev test0
       # cat /sys/class/net/test0/features
       # $DIR/test_tunnel_xmit 10 10.5.2.1
      ip route add 10.5.2.0/24 dev test0
      ip tunnel del test0
      
      The newlink callback is only called in rtnl_netlink, and only if
      the device is new, as it calls register_netdevice internally. Gre
      tunnels are created at 'ip tunnel add' with ioctl SIOCADDTUNNEL,
      which calls ipgre_tunnel_locate, which calls register_netdev.
      rtnl_newlink is called at 'ip link set', but skips ops->newlink
      and the device is up with locking still enabled. The equivalent
      ipip tunnel works fine, btw (just substitute 'method gre' for
      'method ipip').
      
      On kernels before /sys/class/net/*/features was removed [1],
      the first commented out line returns 0x6000 with method gre,
      which indicates that NETIF_F_LLTX (0x1000) is not set. With ipip,
      it reports 0x7000. This test cannot be used on recent kernels where
      the sysfs file is removed (and ETHTOOL_GFEATURES does not currently
      work for tunnel devices, because they lack dev->ethtool_ops).
      
      The second commented out line calls a simple transmission test [2]
      that sends on 24 cores at maximum rate. Results of a single run:
      
      ipip:			19,372,306
      gre before patch:	 4,839,753
      gre after patch:	19,133,873
      
      This patch replicates the condition check in ipgre_newlink to
      ipgre_tunnel_locate. It works for me, both with oseq on and off.
      This is the first time I looked at rtnetlink and iproute2 code,
      though, so someone more knowledgeable should probably check the
      patch. Thanks.
      
      The tail of both functions is now identical, by the way. To avoid
      code duplication, I'll be happy to rework this and merge the two.
      
      [1] http://patchwork.ozlabs.org/patch/104610/
      [2] http://kernel.googlecode.com/files/xmit_udp_parallel.cSigned-off-by: NWillem de Bruijn <willemb@google.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f2b3ee9e
  2. 26 1月, 2012 2 次提交
  3. 23 1月, 2012 2 次提交
    • S
      tcp: md5: using remote adress for md5 lookup in rst packet · 8a622e71
      shawnlu 提交于
      md5 key is added in socket through remote address.
      remote address should be used in finding md5 key when
      sending out reset packet.
      Signed-off-by: Nshawnlu <shawn.lu@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a622e71
    • Y
      tcp: detect loss above high_seq in recovery · 974c1236
      Yuchung Cheng 提交于
      Correctly implement a loss detection heuristic: New sequences (above
      high_seq) sent during the fast recovery are deemed lost when higher
      sequences are SACKed.
      
      Current code does not catch these losses, because tcp_mark_head_lost()
      does not check packets beyond high_seq. The fix is straight-forward by
      checking packets until the highest sacked packet. In addition, all the
      FLAG_DATA_LOST logic are in-effective and redundant and can be removed.
      
      Update the loss heuristic comments. The algorithm above is documented
      as heuristic B, but it is redundant too because heuristic A already
      covers B.
      
      Note that this change only marks some forward-retransmitted packets LOST.
      It does NOT forbid TCP performing further CWR on new losses. A potential
      follow-up patch under preparation is to perform another CWR on "new"
      losses such as
      1) sequence above high_seq is lost (by resetting high_seq to snd_nxt)
      2) retransmission is lost.
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      974c1236
  4. 21 1月, 2012 2 次提交
    • N
      tcp: fix undo after RTO for CUBIC · 5a45f008
      Neal Cardwell 提交于
      This patch fixes CUBIC so that cwnd reductions made during RTOs can be
      undone (just as they already can be undone when using the default/Reno
      behavior).
      
      When undoing cwnd reductions, BIC-derived congestion control modules
      were restoring the cwnd from last_max_cwnd. There were two problems
      with using last_max_cwnd to restore a cwnd during undo:
      
      (a) last_max_cwnd was set to 0 on state transitions into TCP_CA_Loss
      (by calling the module's reset() functions), so cwnd reductions from
      RTOs could not be undone.
      
      (b) when fast_covergence is enabled (which it is by default)
      last_max_cwnd does not actually hold the value of snd_cwnd before the
      loss; instead, it holds a scaled-down version of snd_cwnd.
      
      This patch makes the following changes:
      
      (1) upon undo, revert snd_cwnd to ca->loss_cwnd, which is already, as
      the existing comment notes, the "congestion window at last loss"
      
      (2) stop forgetting ca->loss_cwnd on TCP_CA_Loss events
      
      (3) use ca->last_max_cwnd to check if we're in slow start
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NStephen Hemminger <shemminger@vyatta.com>
      Acked-by: NSangtae Ha <sangtae.ha@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a45f008
    • N
      tcp: fix undo after RTO for BIC · fc16dcd8
      Neal Cardwell 提交于
      This patch fixes BIC so that cwnd reductions made during RTOs can be
      undone (just as they already can be undone when using the default/Reno
      behavior).
      
      When undoing cwnd reductions, BIC-derived congestion control modules
      were restoring the cwnd from last_max_cwnd. There were two problems
      with using last_max_cwnd to restore a cwnd during undo:
      
      (a) last_max_cwnd was set to 0 on state transitions into TCP_CA_Loss
      (by calling the module's reset() functions), so cwnd reductions from
      RTOs could not be undone.
      
      (b) when fast_covergence is enabled (which it is by default)
      last_max_cwnd does not actually hold the value of snd_cwnd before the
      loss; instead, it holds a scaled-down version of snd_cwnd.
      
      This patch makes the following changes:
      
      (1) upon undo, revert snd_cwnd to ca->loss_cwnd, which is already, as
      the existing comment notes, the "congestion window at last loss"
      
      (2) stop forgetting ca->loss_cwnd on TCP_CA_Loss events
      
      (3) use ca->last_max_cwnd to check if we're in slow start
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fc16dcd8
  5. 18 1月, 2012 1 次提交
  6. 17 1月, 2012 2 次提交
  7. 13 1月, 2012 2 次提交
  8. 12 1月, 2012 2 次提交
  9. 10 1月, 2012 1 次提交
  10. 08 1月, 2012 1 次提交
  11. 06 1月, 2012 1 次提交
  12. 31 12月, 2011 1 次提交
  13. 29 12月, 2011 1 次提交
  14. 28 12月, 2011 2 次提交
  15. 23 12月, 2011 9 次提交
  16. 22 12月, 2011 1 次提交
  17. 21 12月, 2011 2 次提交
  18. 20 12月, 2011 2 次提交
  19. 17 12月, 2011 2 次提交
  20. 16 12月, 2011 1 次提交
  21. 15 12月, 2011 1 次提交
  22. 13 12月, 2011 1 次提交