1. 12 5月, 2020 9 次提交
    • E
      sfc: rework handling of (firmware) multicast chaining state · fd14e5fd
      Edward Cree 提交于
      Store the mc_chaining bit in struct efx_mcdi_filter_table, so that common
       code in mcdi_filters.c doesn't need to get it from ef10-specific nic_data.
      Also, probe the firmware workaround just before the call to
       efx_mcdi_filter_table_probe(), rather than in a random other part of the
       driver bringup, to ensure that (a) it gets probed in time and (b) it gets
       reprobed as necessary on resets, no matter how the surrounding code gets
       reorganised and reordered.
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd14e5fd
    • E
      sfc: move 'must restore' flags out of ef10-specific nic_data · e4fe938c
      Edward Cree 提交于
      Common code in mcdi_filters.c uses these flags, so by moving them to
       either struct efx_nic (in the case of must_realloc_vis) or struct
       efx_mcdi_filter_table (for must_restore_rss_contexts and
       must_restore_filters), decouple this code from ef10's nic_data.
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4fe938c
    • E
      sfc: use efx_has_cap for capability checks outside of NIC-specific code · 484a75b1
      Edward Cree 提交于
      Removes some efx_ef10_nic_data references from common code.
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      484a75b1
    • T
      sfc: make capability checking a nic_type function · be904b85
      Tom Zhao 提交于
      Various MCDI functions (especially in filter handling) need to check the
       datapath caps, but those live in nic_data (since they don't exist on
       Siena).  Decouple from ef10-specific data structures by adding check_caps
       to the nic_type, to allow using these functions from non-ef10 drivers.
      
      Also add a convenience macro efx_has_cap() to reduce the amount of
       boilerplate involved in calling it.
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be904b85
    • E
      sfc: move vport_id to struct efx_nic · dfcabb07
      Edward Cree 提交于
      Remove some usage of ef10-specific nic_data structs from common MCDI
       functions, in preparation for using them from a non-EF10 driver.
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dfcabb07
    • B
      net: qed: Disable SRIOV functionality inside kdump kernel · 37d4f8a6
      Bhupesh Sharma 提交于
      Since we have kdump kernel(s) running under severe memory constraint
      it makes sense to disable the qed SRIOV functionality when running the
      kdump kernel as kdump configurations on several distributions don't
      support SRIOV targets for saving the vmcore (see [1] for example).
      
      Currently the qed SRIOV functionality ends up consuming memory in
      the kdump kernel, when we don't really use the same.
      
      An example log seen in the kdump kernel with the SRIOV functionality
      enabled can be seen below (obtained via memstrack tool, see [2]):
       dracut-pre-pivot[676]: ======== Report format module_summary: ========
       dracut-pre-pivot[676]: Module qed using 149.6MB (2394 pages), peak allocation 149.6MB (2394 pages)
      
      This patch disables the SRIOV functionality inside kdump kernel and with
      the same applied the memory consumption goes down:
       dracut-pre-pivot[671]: ======== Report format module_summary: ========
       dracut-pre-pivot[671]: Module qed using 124.6MB (1993 pages), peak allocation 124.7MB (1995 pages)
      
      [1]. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/installing-and-configuring-kdump_managing-monitoring-and-updating-the-kernel#supported-kdump-targets_supported-kdump-configurations-and-targets
      [2]. Memstrack tool: https://github.com/ryncsn/memstrack
      
      Cc: kexec@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Ariel Elior <aelior@marvell.com>
      Cc: GR-everest-linux-l2@marvell.com
      Cc: Manish Chopra <manishc@marvell.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NBhupesh Sharma <bhsharma@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37d4f8a6
    • B
      net: qed*: Reduce RX and TX default ring count when running inside kdump kernel · 73e03097
      Bhupesh Sharma 提交于
      Normally kdump kernel(s) run under severe memory constraint with the
      basic idea being to save the crashdump vmcore reliably when the primary
      kernel panics/hangs.
      
      Currently the qed* ethernet driver ends up consuming a lot of memory in
      the kdump kernel, leading to kdump kernel panic when one tries to save
      the vmcore via ssh/nfs (thus utilizing the services of the underlying
      qed* network interfaces).
      
      An example OOM message log seen in the kdump kernel can be seen here
      [1], with crashkernel size reservation of 512M.
      
      Using tools like memstrack (see [2]), we can track the modules taking up
      the bulk of memory in the kdump kernel and organize the memory usage
      output as per 'highest allocator first'. An example log for the OOM case
      indicates that the qed* modules end up allocating approximately 216M
      memory, which is a large part of the total crashkernel size:
      
       dracut-pre-pivot[676]: ======== Report format module_summary: ========
       dracut-pre-pivot[676]: Module qed using 149.6MB (2394 pages), peak allocation 149.6MB (2394 pages)
       dracut-pre-pivot[676]: Module qede using 65.3MB (1045 pages), peak allocation 65.3MB (1045 pages)
      
      This patch reduces the default RX and TX ring count from 1024 to 64
      when running inside kdump kernel, which leads to a significant memory
      saving.
      
      An example log with the patch applied shows the reduced memory
      allocation in the kdump kernel:
       dracut-pre-pivot[674]: ======== Report format module_summary: ========
       dracut-pre-pivot[674]: Module qed using 141.8MB (2268 pages), peak allocation 141.8MB (2268 pages)
       <..snip..>
      [dracut-pre-pivot[674]: Module qede using 4.8MB (76 pages), peak allocation 4.9MB (78 pages)
      
      Tested crashdump vmcore save via ssh/nfs protocol using underlying qed*
      network interface after applying this patch.
      
      [1] OOM log:
      ------------
      
       kworker/0:6: page allocation failure: order:6,
       mode:0x60c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null)
       kworker/0:6 cpuset=/ mems_allowed=0
       CPU: 0 PID: 145 Comm: kworker/0:6 Not tainted 4.18.0-109.el8.aarch64 #1
       Hardware name: To be filled by O.E.M. Saber/Saber, BIOS 0ACKL025
       01/18/2019
       Workqueue: events work_for_cpu_fn
       Call trace:
        dump_backtrace+0x0/0x188
        show_stack+0x24/0x30
        dump_stack+0x90/0xb4
        warn_alloc+0xf4/0x178
        __alloc_pages_nodemask+0xcac/0xd58
        alloc_pages_current+0x8c/0xf8
        kmalloc_order_trace+0x38/0x108
        qed_iov_alloc+0x40/0x248 [qed]
        qed_resc_alloc+0x224/0x518 [qed]
        qed_slowpath_start+0x254/0x928 [qed]
         __qede_probe+0xf8/0x5e0 [qede]
        qede_probe+0x68/0xd8 [qede]
        local_pci_probe+0x44/0xa8
        work_for_cpu_fn+0x20/0x30
        process_one_work+0x1ac/0x3e8
        worker_thread+0x44/0x448
        kthread+0x130/0x138
        ret_from_fork+0x10/0x18
        Cannot start slowpath
        qede: probe of 0000:05:00.1 failed with error -12
      
      [2]. Memstrack tool: https://github.com/ryncsn/memstrack
      
      Cc: kexec@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Ariel Elior <aelior@marvell.com>
      Cc: GR-everest-linux-l2@marvell.com
      Cc: Manish Chopra <manishc@marvell.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NBhupesh Sharma <bhsharma@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73e03097
    • L
      hinic: add link_ksettings ethtool_ops support · 01f2b3da
      Luo bin 提交于
      add set_link_ksettings implementation and improve the implementation
      of get_link_ksettings
      Signed-off-by: NLuo bin <luobin9@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      01f2b3da
    • G
      net: atarilance: Replace zero-length array with flexible-array · c2dfc7d2
      Gustavo A. R. Silva 提交于
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      sizeof(flexible-array-member) triggers a warning because flexible array
      members have incomplete type[1]. There are some instances of code in
      which the sizeof operator is being incorrectly/erroneously applied to
      zero-length arrays and the result is zero. Such instances may be hiding
      some bugs. So, this work (flexible-array member conversions) will also
      help to get completely rid of those sorts of issues.
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2dfc7d2
  2. 11 5月, 2020 5 次提交
  3. 10 5月, 2020 15 次提交
  4. 09 5月, 2020 11 次提交