1. 07 12月, 2016 1 次提交
  2. 06 12月, 2016 8 次提交
  3. 04 12月, 2016 1 次提交
  4. 03 12月, 2016 1 次提交
  5. 30 11月, 2016 2 次提交
  6. 28 11月, 2016 1 次提交
  7. 25 11月, 2016 1 次提交
  8. 24 11月, 2016 1 次提交
  9. 22 11月, 2016 1 次提交
  10. 17 11月, 2016 6 次提交
  11. 16 11月, 2016 4 次提交
  12. 15 11月, 2016 2 次提交
  13. 14 11月, 2016 2 次提交
  14. 10 11月, 2016 2 次提交
  15. 08 11月, 2016 2 次提交
  16. 01 11月, 2016 1 次提交
    • A
      bgmac: stop clearing DMA receive control register right after it is set · fcdefcca
      Andy Gospodarek 提交于
      Current bgmac code initializes some DMA settings in the receive control
      register for some hardware and then immediately clears those settings.
      Not clearing those settings results in ~420Mbps *improvement* in
      throughput; this system can now receive frames at line-rate on Broadcom
      5871x hardware compared to ~520Mbps today.  I also tested a few other
      values but found there to be no discernible difference in CPU
      utilization even if burst size and prefetching values are different.
      
      On the hardware tested there was no need to keep the code that cleared
      all but bits 16-17, but since there is a wide variety of hardware that
      used this driver (I did not look at all hardware docs for hardware using
      this IP block), I find it wise to move this call up and clear bits just
      after reading the default value from the hardware rather than completely
      removing it.
      
      This is a good candidate for -stable >=3.14 since that is when the code
      that was supposed to improve performance (but did not) was introduced.
      Signed-off-by: NAndy Gospodarek <gospo@broadcom.com>
      Fixes: 56ceecde ("bgmac: initialize the DMA controller of core...")
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Acked-by: NHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fcdefcca
  17. 28 10月, 2016 2 次提交
  18. 24 10月, 2016 1 次提交
  19. 21 10月, 2016 1 次提交
    • J
      ethernet: use net core MTU range checking in more drivers · d894be57
      Jarod Wilson 提交于
      Somehow, I missed a healthy number of ethernet drivers in the last pass.
      Most of these drivers either were in need of an updated max_mtu to make
      jumbo frames possible to enable again. In a few cases, also setting a
      different min_mtu to match previous lower bounds. There are also a few
      drivers that had no upper bounds checking, so they're getting a brand new
      ETH_MAX_MTU that is identical to IP_MAX_MTU, but accessible by includes
      all ethernet and ethernet-like drivers all have already.
      
      acenic:
      - min_mtu = 0, max_mtu = 9000
      
      amazon/ena:
      - min_mtu = 128, max_mtu = adapter->max_mtu
      
      amd/xgbe:
      - min_mtu = 0, max_mtu = 9000
      
      sb1250:
      - min_mtu = 0, max_mtu = 1518
      
      cxgb3:
      - min_mtu = 81, max_mtu = 65535
      
      cxgb4:
      - min_mtu = 81, max_mtu = 9600
      
      cxgb4vf:
      - min_mtu = 81, max_mtu = 65535
      
      benet:
      - min_mtu = 256, max_mtu = 9000
      
      ibmveth:
      - min_mtu = 68, max_mtu = 65535
      
      ibmvnic:
      - min_mtu = adapter->min_mtu, max_mtu = adapter->max_mtu
      - remove now redundant ibmvnic_change_mtu
      
      jme:
      - min_mtu = 1280, max_mtu = 9202
      
      mv643xx_eth:
      - min_mtu = 64, max_mtu = 9500
      
      mlxsw:
      - min_mtu = 0, max_mtu = 65535
      - Basically bypassing the core checks, and instead relying on dynamic
        checks in the respective switch drivers' ndo_change_mtu functions
      
      ns83820:
      - min_mtu = 0
      - remove redundant ns83820_change_mtu, only checked for mtu > 1500
      
      netxen:
      - min_mtu = 0, max_mtu = 8000 (P2), max_mtu = 9600 (P3)
      
      qlge:
      - min_mtu = 1500, max_mtu = 9000
      - driver only supports setting mtu to 1500 or 9000, so the core check only
        rules out < 1500 and > 9000, qlge_change_mtu still needs to check that
        the value is 1500 or 9000
      
      qualcomm/emac:
      - min_mtu = 46, max_mtu = 9194
      
      xilinx_axienet:
      - min_mtu = 64, max_mtu = 9000
      
      Fixes: 61e84623 ("net: centralize net_device min/max MTU checking")
      CC: netdev@vger.kernel.org
      CC: Jes Sorensen <jes@trained-monkey.org>
      CC: Netanel Belgazal <netanel@annapurnalabs.com>
      CC: Tom Lendacky <thomas.lendacky@amd.com>
      CC: Santosh Raspatur <santosh@chelsio.com>
      CC: Hariprasad S <hariprasad@chelsio.com>
      CC: Sathya Perla <sathya.perla@broadcom.com>
      CC: Ajit Khaparde <ajit.khaparde@broadcom.com>
      CC: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
      CC: Somnath Kotur <somnath.kotur@broadcom.com>
      CC: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
      CC: John Allen <jallen@linux.vnet.ibm.com>
      CC: Guo-Fu Tseng <cooldavid@cooldavid.org>
      CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      CC: Jiri Pirko <jiri@mellanox.com>
      CC: Ido Schimmel <idosch@mellanox.com>
      CC: Manish Chopra <manish.chopra@qlogic.com>
      CC: Sony Chacko <sony.chacko@qlogic.com>
      CC: Rajesh Borundia <rajesh.borundia@qlogic.com>
      CC: Timur Tabi <timur@codeaurora.org>
      CC: Anirudha Sarangi <anirudh@xilinx.com>
      CC: John Linn <John.Linn@xilinx.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d894be57