1. May 11, 2022
  2. May 09, 2022
  3. May 06, 2022
  4. May 05, 2022
  5. May 04, 2022
  6. May 03, 2022
    • Paolo Abeni's avatar
      Merge tag 'mlx5-updates-2022-05-02' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 2b68abf9
      Paolo Abeni authored
      Saeed Mahameed says:
      
      ====================
      mlx5-updates-2022-05-02
      
      1) Trivial Misc updates to mlx5 driver
      
      2) From Mark Bloch: Flow steering, general steering refactoring/cleaning
      
      An issue with flow steering deletion flow (when creating a rule without
      dests) turned out to be easy to fix but during the fix some issue
      with the flow steering creation/deletion flows have been found.
      
      The following patch series tries to fix long standing issues with flow
      steering code and hopefully preventing silly future bugs.
      
        A) Fix an issue where a proper dest type wasn't assigned.
        B) Refactor and fix dests enums values, refactor deletion
           function and do proper bookkeeping of dests.
        C) Change mlx5_del_flow_rules() to delete rules when there are no
           no more rules attached associated with an FTE.
        D) Don't call hard coded deletion function but use the node's
           defined one.
        E) Add a WARN_ON() to catch future bugs when an FTE with dests
           is deleted.
      
      * tag 'mlx5-updates-2022-05-02' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux:
        net/mlx5: fs, an FTE should have no dests when deleted
        net/mlx5: fs, call the deletion function of the node
        net/mlx5: fs, delete the FTE when there are no rules attached to it
        net/mlx5: fs, do proper bookkeeping for forward destinations
        net/mlx5: fs, add unused destination type
        net/mlx5: fs, jump to exit point and don't fall through
        net/mlx5: fs, refactor software deletion rule
        net/mlx5: fs, split software and IFC flow destination definitions
        net/mlx5e: TC, set proper dest type
        net/mlx5e: Remove unused mlx5e_dcbnl_build_rep_netdev function
        net/mlx5e: Drop error CQE handling from the XSK RX handler
        net/mlx5: Print initializing field in case of timeout
        net/mlx5: Delete redundant default assignment of runtime devlink params
        net/mlx5: Remove useless kfree
        net/mlx5: use kvfree() for kvzalloc() in mlx5_ct_fs_smfs_matcher_create
      ====================
      
      Link: https://lore.kernel.org/r/
      
      
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      2b68abf9
    • Paolo Abeni's avatar
      Merge branch 'mlxsw-remove-size-limitations-on-egress-descriptor-buffer' · f4f1fd76
      Paolo Abeni authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Remove size limitations on egress descriptor buffer
      
      Petr says:
      
      Spectrum machines have two resources related to keeping packets in an
      internal buffer: bytes (allocated in cell-sized units) for packet payload,
      and descriptors, for keeping headers. Currently, mlxsw only configures the
      bytes part of the resource management.
      
      Spectrum switches permit a full parallel configuration for the descriptor
      resources, including port-pool and port-TC-pool quotas. By default, these
      are all configured to use pool 14, with an infinite quota. The ingress pool
      14 is then infinite in size.
      
      However, egress pool 14 has finite size by default. The size is chip
      dependent, but always much lower than what the chip actually permits. As a
      result, we can easily construct workloads that exhaust the configured
      descriptor limit.
      
      Going forward, mlxsw will have to fix this issue properly by maintaining
      descriptor buffer sizes, TC bindings, and quotas that match the
      architecture recommendation. Short term, fix the issue by configuring the
      egress descriptor pool to be infinite in size as well. This will maintain
      the same configuration philosophy, but will unlock all chip resources to be
      usable.
      
      In this patchset, patch #1 first adds the "desc" field into the pool
      configuration register. Then in patch #2, the new field is used to
      configure both ingress and egress pool 14 as infinite.
      
      In patches #3 and #4, add a selftest that verifies that a large burst
      can be absorbed by the shared buffer. This test specifically exercises a
      scenario where descriptor buffer is the limiting factor and the test
      fails without the above patches.
      ====================
      
      Link: https://lore.kernel.org/r/20220502084926.365268-1-idosch@nvidia.com
      
      
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      f4f1fd76