1. 24 12月, 2010 11 次提交
  2. 23 12月, 2010 7 次提交
  3. 22 12月, 2010 9 次提交
  4. 21 12月, 2010 13 次提交
    • J
      drivers/net/*/: Use static const · 215faf9c
      Joe Perches 提交于
      Using static const generally increases object text and decreases data size.
      It also generally decreases overall object size.
      Signed-off-by: NJoe Perches <joe@perches.com>
      215faf9c
    • J
      tulip: Use DEFINE_PCI_DEVICE_TABLE and static const · 75a84eb5
      Joe Perches 提交于
      Moves the PCI table to the right read-only section.
      Using static const generally increases object text and decreases data size.
      It also generally decreases overall object size.
      Signed-off-by: NJoe Perches <joe@perches.com>
      75a84eb5
    • J
      usb: Use static const, consolidate code · 5591c75d
      Joe Perches 提交于
      Using static const generally increases object text and decreases data size.
      It also generally decreases overall object size.
      
      Consolidate duplicated code into new fix_crc_bug function
      and declare data in that function static const.
      Signed-off-by: NJoe Perches <joe@perches.com>
      5591c75d
    • J
      drivers/net/*.c: Use static const · b6bc7650
      Joe Perches 提交于
      Using static const generally increases object text and decreases data size.
      It also generally decreases overall object size.
      Signed-off-by: NJoe Perches <joe@perches.com>
      b6bc7650
    • J
      tg3: Use DEFINE_PCI_DEVICE_TABLE · 895950c2
      Joe Perches 提交于
      Moves the PCI tables to the right read-only section.
      Signed-off-by: NJoe Perches <joe@perches.com>
      895950c2
    • N
      TCP: increase default initial receive window. · 356f0398
      Nandita Dukkipati 提交于
      This patch changes the default initial receive window to 10 mss
      (defined constant). The default window is limited to the maximum
      of 10*1460 and 2*mss (when mss > 1460).
      
      draft-ietf-tcpm-initcwnd-00 is a proposal to the IETF that recommends
      increasing TCP's initial congestion window to 10 mss or about 15KB.
      Leading up to this proposal were several large-scale live Internet
      experiments with an initial congestion window of 10 mss (IW10), where
      we showed that the average latency of HTTP responses improved by
      approximately 10%. This was accompanied by a slight increase in
      retransmission rate (0.5%), most of which is coming from applications
      opening multiple simultaneous connections. To understand the extreme
      worst case scenarios, and fairness issues (IW10 versus IW3), we further
      conducted controlled testbed experiments. We came away finding minimal
      negative impact even under low link bandwidths (dial-ups) and small
      buffers.  These results are extremely encouraging to adopting IW10.
      
      However, an initial congestion window of 10 mss is useless unless a TCP
      receiver advertises an initial receive window of at least 10 mss.
      Fortunately, in the large-scale Internet experiments we found that most
      widely used operating systems advertised large initial receive windows
      of 64KB, allowing us to experiment with a wide range of initial
      congestion windows. Linux systems were among the few exceptions that
      advertised a small receive window of 6KB. The purpose of this patch is
      to fix this shortcoming.
      
      References:
      1. A comprehensive list of all IW10 references to date.
      http://code.google.com/speed/protocols/tcpm-IW10.html
      
      2. Paper describing results from large-scale Internet experiments with IW10.
      http://ccr.sigcomm.org/drupal/?q=node/621
      
      3. Controlled testbed experiments under worst case scenarios and a
      fairness study.
      http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf
      
      4. Raw test data from testbed experiments (Linux senders/receivers)
      with initial congestion and receive windows of both 10 mss.
      http://research.csc.ncsu.edu/netsrv/?q=content/iw10
      
      5. Internet-Draft. Increasing TCP's Initial Window.
      https://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/Signed-off-by: NNandita Dukkipati <nanditad@google.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      356f0398
    • E
      net_sched: sch_sfq: better struct layouts · eda83e3b
      Eric Dumazet 提交于
      Here is a respin of patch.
      
      I'll send a short patch to make SFQ more fair in presence of large
      packets as well.
      
      Thanks
      
      [PATCH v3 net-next-2.6] net_sched: sch_sfq: better struct layouts
      
      This patch shrinks sizeof(struct sfq_sched_data)
      from 0x14f8 (or more if spinlocks are bigger) to 0x1180 bytes, and
      reduce text size as well.
      
         text    data     bss     dec     hex filename
         4821     152       0    4973    136d old/net/sched/sch_sfq.o
         4627     136       0    4763    129b new/net/sched/sch_sfq.o
      
      All data for a slot/flow is now grouped in a compact and cache friendly
      structure, instead of being spreaded in many different points.
      
      struct sfq_slot {
              struct sk_buff  *skblist_next;
              struct sk_buff  *skblist_prev;
              sfq_index       qlen; /* number of skbs in skblist */
              sfq_index       next; /* next slot in sfq chain */
              struct sfq_head dep; /* anchor in dep[] chains */
              unsigned short  hash; /* hash value (index in ht[]) */
              short           allot; /* credit for this slot */
      };
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Jarek Poplawski <jarkao2@gmail.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eda83e3b
    • D
    • E
      net_sched: sch_sfq: fix allot handling · aa3e2199
      Eric Dumazet 提交于
      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: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa3e2199
    • E
      net_sched: sch_sfq: add backlog info in sfq_dump_class_stats() · c4266263
      Eric Dumazet 提交于
      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: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c4266263
    • J
      rtlwifi: use alloc_workqueue · 3d986b25
      John W. Linville 提交于
      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: NJohn W. Linville <linville@tuxdriver.com>
      Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Acked-by: NTejun Heo <tj@kernel.org>
      3d986b25
    • F
      ath9k: do not limit the chainmask to 1 for legacy mode · d4d5dc3d
      Felix Fietkau 提交于
      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: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d4d5dc3d
    • F
      ath9k_hw: fix PA predistortion HT40 mask · f1a8abb0
      Felix Fietkau 提交于
      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: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f1a8abb0