1. 11 10月, 2007 8 次提交
  2. 08 10月, 2007 1 次提交
    • I
      [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed · 48611c47
      Ilpo Järvinen 提交于
      When only GSO skb was partially ACKed, no hints are reset,
      therefore fastpath_cnt_hint must be tweaked too or else it can
      corrupt fackets_out. The corruption to occur, one must have
      non-trivial ACK/SACK sequence, so this bug is not very often
      that harmful. There's a fackets_out state reset in TCP because
      fackets_out is known to be inaccurate and that fixes the issue
      eventually anyway.
      
      In case there was also at least one skb that got fully ACKed,
      the fastpath_skb_hint is set to NULL which causes a recount for
      fastpath_cnt_hint (the old value won't be accessed anymore),
      thus it can safely be decremented without additional checking.
      
      Reported by Cedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48611c47
  3. 01 9月, 2007 1 次提交
  4. 31 8月, 2007 1 次提交
  5. 27 8月, 2007 1 次提交
  6. 03 8月, 2007 2 次提交
  7. 31 7月, 2007 3 次提交
    • I
      [TCP]: Bidir flow must not disregard SACK blocks for lost marking · b8ed601c
      Ilpo Järvinen 提交于
      It's possible that new SACK blocks that should trigger new LOST
      markings arrive with new data (which previously made is_dupack
      false). In addition, I think this fixes a case where we get
      a cumulative ACK with enough SACK blocks to trigger the fast
      recovery (is_dupack would be false there too).
      
      I'm not completely pleased with this solution because readability
      of the code is somewhat questionable as 'is_dupack' in SACK case
      is no longer about dupacks only but would mean something like
      'lost_marker_work_todo' too... But because of Eifel stuff done
      in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to
      the if statement which seems attractive solution. Nevertheless,
      I didn't like adding another variable just for that either... :-)
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8ed601c
    • I
      [TCP]: Fix ratehalving with bidirectional flows · 1e757f99
      Ilpo Järvinen 提交于
      Actually, the ratehalving seems to work too well, as cwnd is
      reduced on every second ACK even though the packets in flight
      remains unchanged. Recoveries in a bidirectional flows suffer
      quite badly because of this, both NewReno and SACK are affected.
      
      After this patch, rate halving is performed for ACK only if
      packets in flight was supposedly changed too.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e757f99
    • S
      [TCP]: congestion control API pass RTT in microseconds · 30cfd0ba
      Stephen Hemminger 提交于
      This patch changes the API for the callback that is done after an ACK is
      received. It solves a couple of issues:
      
        * Some congestion controls want higher resolution value of RTT
          (controlled by TCP_CONG_RTT_SAMPLE flag). These don't really want a ktime, but
          all compute a RTT in microseconds.
      
        * Other congestion control could use RTT at jiffies resolution.
      
      To keep API consistent the units should be the same for both cases, just the
      resolution should change.
      Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30cfd0ba
  8. 18 7月, 2007 1 次提交
  9. 15 7月, 2007 1 次提交
  10. 16 6月, 2007 2 次提交
  11. 15 6月, 2007 1 次提交
  12. 13 6月, 2007 1 次提交
  13. 04 6月, 2007 1 次提交
  14. 20 5月, 2007 2 次提交
  15. 30 4月, 2007 2 次提交
  16. 26 4月, 2007 12 次提交