1. 19 2月, 2019 1 次提交
  2. 30 8月, 2018 1 次提交
  3. 10 7月, 2018 1 次提交
  4. 23 6月, 2018 1 次提交
  5. 19 4月, 2018 3 次提交
  6. 18 1月, 2018 1 次提交
  7. 16 11月, 2017 1 次提交
    • M
      mm: remove __GFP_COLD · 453f85d4
      Mel Gorman 提交于
      As the page free path makes no distinction between cache hot and cold
      pages, there is no real useful ordering of pages in the free list that
      allocation requests can take advantage of.  Juding from the users of
      __GFP_COLD, it is likely that a number of them are the result of copying
      other sites instead of actually measuring the impact.  Remove the
      __GFP_COLD parameter which simplifies a number of paths in the page
      allocator.
      
      This is potentially controversial but bear in mind that the size of the
      per-cpu pagelists versus modern cache sizes means that the whole per-cpu
      list can often fit in the L3 cache.  Hence, there is only a potential
      benefit for microbenchmarks that alloc/free pages in a tight loop.  It's
      even worse when THP is taken into account which has little or no chance
      of getting a cache-hot page as the per-cpu list is bypassed and the
      zeroing of multiple pages will thrash the cache anyway.
      
      The truncate microbenchmarks are not shown as this patch affects the
      allocation path and not the free path.  A page fault microbenchmark was
      tested but it showed no sigificant difference which is not surprising
      given that the __GFP_COLD branches are a miniscule percentage of the
      fault path.
      
      Link: http://lkml.kernel.org/r/20171018075952.10627-9-mgorman@techsingularity.netSigned-off-by: NMel Gorman <mgorman@techsingularity.net>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      453f85d4
  8. 08 11月, 2017 1 次提交
  9. 09 9月, 2017 1 次提交
  10. 08 8月, 2017 4 次提交
  11. 08 6月, 2017 1 次提交
  12. 12 5月, 2017 1 次提交
  13. 25 4月, 2017 1 次提交
  14. 16 3月, 2017 1 次提交
    • A
      mqprio: Modify mqprio to pass user parameters via ndo_setup_tc. · 56f36acd
      Amritha Nambiar 提交于
      The configurable priority to traffic class mapping and the user specified
      queue ranges are used to configure the traffic class, overriding the
      hardware defaults when the 'hw' option is set to 0. However, when the 'hw'
      option is non-zero, the hardware QOS defaults are used.
      
      This patch makes it so that we can pass the data the user provided to
      ndo_setup_tc. This allows us to pull in the queue configuration if the
      user requested it as well as any additional hardware offload type
      requested by using a value other than 1 for the hw value.
      
      Finally it also provides a means for the device driver to return the level
      supported for the offload type via the qopt->hw value. Previously we were
      just always assuming the value to be 1, in the future values beyond just 1
      may be supported.
      Signed-off-by: NAmritha Nambiar <amritha.nambiar@intel.com>
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56f36acd
  15. 11 2月, 2017 1 次提交
  16. 31 1月, 2017 1 次提交
  17. 11 1月, 2017 1 次提交
  18. 08 1月, 2017 4 次提交
  19. 11 12月, 2016 1 次提交
  20. 17 11月, 2016 1 次提交
  21. 27 10月, 2016 2 次提交
  22. 18 10月, 2016 1 次提交
    • J
      ethernet: use core min/max MTU checking · 44770e11
      Jarod Wilson 提交于
      et131x: min_mtu 64, max_mtu 9216
      
      altera_tse: min_mtu 64, max_mtu 1500
      
      amd8111e: min_mtu 60, max_mtu 9000
      
      bnad: min_mtu 46, max_mtu 9000
      
      macb: min_mtu 68, max_mtu 1500 or 10240 depending on hardware capability
      
      xgmac: min_mtu 46, max_mtu 9000
      
      cxgb2: min_mtu 68, max_mtu 9582 (pm3393) or 9600 (vsc7326)
      
      enic: min_mtu 68, max_mtu 9000
      
      gianfar: min_mtu 50, max_mu 9586
      
      hns_enet: min_mtu 68, max_mtu 9578 (v1) or 9706 (v2)
      
      ksz884x: min_mtu 60, max_mtu 1894
      
      myri10ge: min_mtu 68, max_mtu 9000
      
      natsemi: min_mtu 64, max_mtu 2024
      
      nfp: min_mtu 68, max_mtu hardware-specific
      
      forcedeth: min_mtu 64, max_mtu 1500 or 9100, depending on hardware
      
      pch_gbe: min_mtu 46, max_mtu 10300
      
      pasemi_mac: min_mtu 64, max_mtu 9000
      
      qcaspi: min_mtu 46, max_mtu 1500
      - remove qcaspi_netdev_change_mtu as it is now redundant
      
      rocker: min_mtu 68, max_mtu 9000
      
      sxgbe: min_mtu 68, max_mtu 9000
      
      stmmac: min_mtu 46, max_mtu depends on hardware
      
      tehuti: min_mtu 60, max_mtu 16384
      - driver had no max mtu checking, but product docs say 16k jumbo packets
        are supported by the hardware
      
      netcp: min_mtu 68, max_mtu 9486
      - remove netcp_ndo_change_mtu as it is now redundant
      
      via-velocity: min_mtu 64, max_mtu 9000
      
      octeon: min_mtu 46, max_mtu 65370
      
      CC: netdev@vger.kernel.org
      CC: Mark Einon <mark.einon@gmail.com>
      CC: Vince Bridgers <vbridger@opensource.altera.com>
      CC: Rasesh Mody <rasesh.mody@qlogic.com>
      CC: Nicolas Ferre <nicolas.ferre@atmel.com>
      CC: Santosh Raspatur <santosh@chelsio.com>
      CC: Hariprasad S <hariprasad@chelsio.com>
      CC:  Christian Benvenuti <benve@cisco.com>
      CC: Sujith Sankar <ssujith@cisco.com>
      CC: Govindarajulu Varadarajan <_govind@gmx.com>
      CC: Neel Patel <neepatel@cisco.com>
      CC: Claudiu Manoil <claudiu.manoil@freescale.com>
      CC: Yisen Zhuang <yisen.zhuang@huawei.com>
      CC: Salil Mehta <salil.mehta@huawei.com>
      CC: Hyong-Youb Kim <hykim@myri.com>
      CC: Jakub Kicinski <jakub.kicinski@netronome.com>
      CC: Olof Johansson <olof@lixom.net>
      CC: Jiri Pirko <jiri@resnulli.us>
      CC: Byungho An <bh74.an@samsung.com>
      CC: Girish K S <ks.giri@samsung.com>
      CC: Vipul Pandya <vipul.pandya@samsung.com>
      CC: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      CC: Alexandre Torgue <alexandre.torgue@st.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Wingman Kwok <w-kwok2@ti.com>
      CC: Murali Karicheri <m-karicheri2@ti.com>
      CC: Francois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44770e11
  23. 05 5月, 2016 1 次提交
  24. 04 3月, 2016 1 次提交
    • J
      net: relax setup_tc ndo op handle restriction · 5eb4dce3
      John Fastabend 提交于
      I added this check in setup_tc to multiple drivers,
      
       if (handle != TC_H_ROOT || tc->type != TC_SETUP_MQPRIO)
      
      Unfortunately restricting to TC_H_ROOT like this breaks the old
      instantiation of mqprio to setup a hardware qdisc. This patch
      relaxes the test to only check the type to make it equivalent
      to the check before I broke it. With this the old instantiation
      continues to work.
      
      A good smoke test is to setup mqprio with,
      
      # tc qdisc add dev eth4 root mqprio num_tc 8 \
        map 0 1 2 3 4 5 6 7 \
        queues 0@0 1@1 2@2 3@3 4@4 5@5 6@6 7@7
      
      Fixes: e4c6734e ("net: rework ndo tc op to consume additional qdisc handle paramete")
      Reported-by: NSingh Krishneil <krishneil.k.singh@intel.com>
      Reported-by: NJake Keller <jacob.e.keller@intel.com>
      CC: Murali Karicheri <m-karicheri2@ti.com>
      CC: Shradha Shah <sshah@solarflare.com>
      CC: Or Gerlitz <ogerlitz@mellanox.com>
      CC: Ariel Elior <ariel.elior@qlogic.com>
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      CC: Bruce Allan <bruce.w.allan@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: Don Skidmore <donald.c.skidmore@intel.com>
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5eb4dce3
  25. 23 2月, 2016 1 次提交
    • S
      netcp: use pointer to fix build fail · 0c71de66
      Sudip Mukherjee 提交于
      While building keystone_defconfig of arm we are getting build failure
      with the error:
      
      drivers/net/ethernet/ti/netcp_core.c:1846:31: error: invalid type argument of '->' (have 'struct tc_to_netdev')
        if (handle != TC_H_ROOT || tc->type != TC_SETUP_MQPRIO)
                                     ^
      drivers/net/ethernet/ti/netcp_core.c:1851:35: error: invalid type argument of '->' (have 'struct tc_to_netdev')
            (dev->real_num_tx_queues < tc->tc))
                                         ^
      drivers/net/ethernet/ti/netcp_core.c:1855:8: error: invalid type argument of '->' (have 'struct tc_to_netdev')
        if (tc->tc) {
              ^
      drivers/net/ethernet/ti/netcp_core.c:1856:28: error: invalid type argument of '->' (have 'struct tc_to_netdev')
         netdev_set_num_tc(dev, tc->tc);
                                  ^
      drivers/net/ethernet/ti/netcp_core.c:1857:21: error: invalid type argument of '->' (have 'struct tc_to_netdev')
         for (i = 0; i < tc->tc; i++)
                           ^
      drivers/net/ethernet/ti/netcp_core.c: At top level:
      drivers/net/ethernet/ti/netcp_core.c:1879:2: warning: initialization from incompatible pointer type
        .ndo_setup_tc  = netcp_setup_tc,
        ^
      
      The callback of ndo_setup_tc should be:
      int (*ndo_setup_tc)(struct net_device *dev, u32 handle, __be16 protocol,
                          struct tc_to_netdev *tc);
      
      But we missed marking the last argument as a pointer.
      
      Fixes: 16e5cc64 ("net: rework setup_tc ndo op to consume general tc operand")
      CC: John Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c71de66
  26. 22 2月, 2016 3 次提交
  27. 17 2月, 2016 2 次提交
  28. 19 12月, 2015 1 次提交
    • A
      netcp: fix regression in receive processing · 958d104e
      Arnd Bergmann 提交于
      A cleanup patch I did was unfortunately wrong and introduced
      multiple serious bugs in the netcp rx processing, as indicated
      by these correct gcc warnings:
      
      drivers/net/ethernet/ti/netcp_core.c:776:14: warning: 'buf_ptr' may be used uninitialized in this function [-Wuninitialized]
      drivers/net/ethernet/ti/netcp_core.c:687:14: warning: 'ptr' may be used uninitialized in this function [-Wuninitialized]
      
      I have checked the patch once more and found that a call to
      get_pkt_info() accidentally got removed in netcp_free_rx_desc_chain,
      and netcp_process_one_rx_packet no longer retrieved the correct
      buffer length. This patch should fix all the known problems,
      but I did not test on real hardware.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 89907779 ("netcp: try to reduce type confusion in descriptors")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      958d104e