1. 23 Dec, 2010 11 commits
  2. 22 Dec, 2010 7 commits
  3. 21 Dec, 2010 16 commits
  4. 20 Dec, 2010 6 commits
    • David S. Miller's avatar
    • Eric Dumazet's avatar
      net_sched: sch_sfq: fix allot handling · aa3e2199
      Eric Dumazet authored
      When deploying SFQ/IFB here at work, I found the allot management was
      pretty wrong in sfq, even changing allot from short to int...
      
      We should init allot for each new flow, not using a previous value found
      in slot.
      
      Before patch, I saw bursts of several packets per flow, apparently
      denying the default "quantum 1514" limit I had on my SFQ class.
      
      class sfq 11:1 parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 7p requeues 0 
       allot 11546 
      
      class sfq 11:46 parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 1p requeues 0 
       allot -23873 
      
      class sfq 11:78 parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 5p requeues 0 
       allot 11393 
      
      After patch, better fairness among each flow, allot limit being
      respected, allot is positive :
      
      class sfq 11:e parent 11: 
       (dropped 0, overlimits 0 requeues 86) 
       backlog 0b 3p requeues 86 
       allot 596 
      
      class sfq 11:94 parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 3p requeues 0 
       allot 1468 
      
      class sfq 11:a4 parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 4p requeues 0 
       allot 650 
      
      class sfq 11:bb parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 3p requeues 0 
       allot 596 
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aa3e2199
    • Eric Dumazet's avatar
      net_sched: sch_sfq: add backlog info in sfq_dump_class_stats() · c4266263
      Eric Dumazet authored
      We currently return for each active SFQ slot the number of packets in
      queue. We can also give number of bytes accounted for these packets.
      
      tc -s class show dev ifb0
      
      Before patch :
      
      class sfq 11:3d9 parent 11:
       (dropped 0, overlimits 0 requeues 0)
       backlog 0b 3p requeues 0
       allot 1266
      
      After patch :
      
      class sfq 11:3e4 parent 11:
       (dropped 0, overlimits 0 requeues 0)
       backlog 4380b 3p requeues 0
       allot 1212
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4266263
    • John W. Linville's avatar
      rtlwifi: use alloc_workqueue · 3d986b25
      John W. Linville authored
      create_workqueue is deprecated.  The workqueue usage does not seem to
      demand any special treatment, so do not set any flags either.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Tested-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      3d986b25
    • Felix Fietkau's avatar
      ath9k: do not limit the chainmask to 1 for legacy mode · d4d5dc3d
      Felix Fietkau authored
      Restricting the chainmask to 1 for legacy mode disables useful features
      such as MRC, and it reduces the available transmit power.
      I can't think of a good reason to do this in legacy mode, so let's just
      get rid of that code.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d4d5dc3d
    • Felix Fietkau's avatar
      ath9k_hw: fix PA predistortion HT40 mask · f1a8abb0
      Felix Fietkau authored
      The commit 'ath9k_hw: Disable PAPRD for rates with low Tx power' changed
      the code that sets the PAPRD rate masks to use only either the HT20 mask
      or the HT40 mask. This is wrong, as the hardware can still use HT20 rates
      even when configured for HT40, and the operating channel mode does not
      affect PAPRD operation.
      The register for the HT40 rate mask is applied as a mask on top of the
      other registers to selectively disable PAPRD for specific rates on HT40
      packets only.
      This patch changes the code back to the old behavior which matches the
      intended use of these registers. While with current cards this should not
      make any practical difference (according to Atheros, the HT20 and HT40
      mask should always be equal), it is more correct that way, and maybe
      the HT40 mask will be used for some rare corner cases in the future.
      
      Cc: Vasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f1a8abb0