Skip to content
  1. Feb 02, 2023
  2. Feb 01, 2023
    • Jakub Kicinski's avatar
      Merge branch 'net-ipa-remaining-ipa-v5-0-support' · dd25cfab
      Jakub Kicinski authored
      Alex Elder says:
      
      ====================
      net: ipa: remaining IPA v5.0 support
      
      This series includes almost all remaining IPA code changes required
      to support IPA v5.0.  IPA register definitions and configuration
      data for IPA v5.0 will be sent later (soon).  Note that the GSI
      register definitions still require work.  GSI for IPA v5.0 supports
      up to 256 (rather than 32) channels, and this changes the way GSI
      register offsets are calculated.  A few GSI register fields also
      change.
      
      The first patch in this series increases the number of IPA endpoints
      supported by the driver, from 32 to 36.  The next updates the width
      of the destination field for the IP_PACKET_INIT immediate command so
      it can represent up to 256 endpoints rather than just 32.  The next
      adds a few definitions of some IPA registers and fields that are
      first available in IPA v5.0.
      
      The next two patches update the code that handles router and filter
      table caches.  Previously these were referred to as "hashed" tables,
      and the IPv4 and IPv6 tables are now combined into one "unified"
      table.  The sixth and seventh patches add support for a new pulse
      generator, which allows time periods to be specified with a wider
      range of clock resolution.  And the last patch just defines two new
      memory regions that were not previously used.
      ====================
      
      Link: https://lore.kernel.org/r/20230130210158.4126129-1-elder@linaro.org
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      dd25cfab
    • Alex Elder's avatar
      net: ipa: define two new memory regions · 5157d6bf
      Alex Elder authored
      
      
      IPA v5.0 uses two memory regions not previously used.  Define them
      and treat them as valid only for IPA v5.0.
      
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5157d6bf
    • Alex Elder's avatar
      net: ipa: support a third pulse register · 2cdbcbfd
      Alex Elder authored
      
      
      The AP has third pulse generator available starting with IPA v5.0.
      Redefine ipa_qtime_val() to support that possibility.  Pass the IPA
      pointer as an argument so the version can be determined.  And stop
      using the sign of the returned tick count to indicate which of two
      pulse generators to use.
      
      Instead, have the caller provide the address of a variable that will
      hold the selected pulse generator for the Qtime value.  And for
      version 5.0, check whether the third pulse generator best represents
      the time period.
      
      Add code in ipa_qtime_config() to configure the fourth pulse
      generator for IPA v5.0+; in that case configure both the third and
      fourth pulse generators to use 10 msec granularity.
      
      Consistently use "ticks" for local variables that represent a tick
      count.
      
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2cdbcbfd
    • Alex Elder's avatar
      net: ipa: greater timer granularity options · 32079a4a
      Alex Elder authored
      
      
      Starting with IPA v5.0, the head-of-line blocking timer has more
      than two pulse generators available to define timer granularity.
      To prepare for that, change the way the field value is encoded
      to use ipa_reg_encode() rather than ipa_reg_bit().
      
      The aggregation granularity selection could (in principle) also use
      an additional pulse generator starting with IPA v5.0.  Encode the
      AGGR_GRAN_SEL field differently to allow that as well.
      
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      32079a4a
    • Alex Elder's avatar
      net: ipa: support zeroing new cache tables · a08cedc3
      Alex Elder authored
      
      
      IPA v5.0+ separates the configuration of entries in the cached
      (previously "hashed") routing and filtering tables into distinct
      registers.  Previously a single "filter and router" register updated
      entries in both tables at once; now the routing and filter table
      caches have separate registers that define their content.
      
      This patch updates the code that zeroes entries in the cached filter
      and router tables to support IPA versions including v5.0+.
      
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a08cedc3
    • Alex Elder's avatar
      net: ipa: update table cache flushing · 8e7c89d8
      Alex Elder authored
      
      
      Update the code that causes filter and router table caches to be
      flushed so that it supports IPA versions 5.0+.  It adds a comment in
      ipa_hardware_config_hashing() that explains that cacheing does not
      need to be enabled, just as before, because it's enabled by default.
      (For the record, the FILT_ROUT_CACHE_CFG register would have been
      used if we wanted to explicitly enable these.)
      
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8e7c89d8
    • Alex Elder's avatar
      net: ipa: define IPA v5.0+ registers · 8ba59716
      Alex Elder authored
      
      
      Define some new registers that appear starting with IPA v5.0, along
      with enumerated types identifying their fields.  Code that uses
      these will be added by upcoming patches.
      
      Most of the new registers are related to filter and routing tables,
      and in particular, their "hashed" variant.  These tables are better
      described as "cached", where a hash value determines which entries
      are cached.  From now on, naming related to this functionality will
      use "cache" instead of "hash", and that is reflected in these new
      register names.  Some registers for managing these caches and their
      contents have changed as well.
      
      A few other new field definitions for registers (unrelated to table
      caches) are also defined.
      
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8ba59716
    • Alex Elder's avatar
      net: ipa: extend endpoints in packet init command · c84ddc11
      Alex Elder authored
      
      
      The IP_PACKET_INIT immediate command defines the destination
      endpoint to which a packet should be sent.  Prior to IPA v5.0, a
      5 bit field in that command represents the endpoint, but starting
      with IPA v5.0, the field is extended to 8 bits to support more than
      32 endpoints.
      
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c84ddc11
    • Alex Elder's avatar
      net: ipa: support more endpoints · 07abde54
      Alex Elder authored
      
      
      Increase the number of endpoints supported by the driver to 36,
      which IPA v5.0 supports.  This makes it impossible to check at build
      time whether the supported number is too big to fit within the
      (5-bit) PACKET_INIT destination endpoint field.  Instead, convert
      the build time check to compare against what fits in 8 bits.
      
      Add a check in ipa_endpoint_config() to also ensure the hardware
      reports an endpoint count that's in the expected range.  Just
      open-code 32 as the limit (the PACKET_INIT field mask is not
      available where we'd want to use it).
      
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      07abde54
    • Jakub Kicinski's avatar
      Merge tag 'mlx5-updates-2023-01-30' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 71af6a2d
      Jakub Kicinski authored
      Saeed Mahameed says:
      
      ====================
      mlx5-updates-2023-01-30
      
      Add fast update encryption key
      
      Jianbo Liu Says:
      ================
      
      Data encryption keys (DEKs) are the keys used for data encryption and
      decryption operations. Starting from version 22.33.0783, firmware is
      optimized to accelerate the update of user keys into DEK object in
      hardware. The support for bulk allocation and destruction of DEK
      objects is added, and the bulk allocated DEKs are uninitialized, as
      the bulk creation requires no input key. When offload
      encryption/decryption, user gets one object from a bulk, and updates
      key by a new "modify DEK" command. This command is the same as create
      DEK object, but requires no heavy context memory allocation in
      firmware, which consumes most cpu cycles of the create DEK command.
      
      DEKs are cached internally by the NIC, so invalidating internal NIC
      caches is required before reusing DEKs. The SYNC_CRYPTO command is
      added to support it. DEK object can be reused, the keys in it can be
      updated after this command is executed.
      
      This patchset enhances the key creation and destruction flow, to get
      use of this new feature. Any user, for example, ktls, ipsec and
      macsec, can use it to offload keys. But, only ktls uses it, as others
      don't need many keys, and caching two many DEKs in pool is wasteful.
      
      There are two new data struts added:
          a. DEK pool. One pool is created for each key type. The bulks by
      the type, are placed in the pool's different bulk lists, according to
      the number of available and in_used DEKs in the bulk.
          b. DEK bulk. All DEKs in one bulk allocation are store here. There
      are two bitmaps to indicate the state of each DEK.
      
      New APIs are then added. When user need a DEK object,
          a. Fetch one bulk with avail DEKs, from the partial_list or
      avail_list, otherwise create new one.
          b. Pick one DEK, and set its need_sync and in_used bits to 1.
      Move the bulk to full_list if no more available keys, or put it to
      partial_list if the bulk is newly created.
          c. Update DEK object's key with user key, by the "modify DEK"
      command.
          d. Return DEK struct to user, then it gets the object id and fills
      it into the offload commands.
      When user free a DEK,
          a. Set in_use bit to 0. If all need_sync bits are 1 and all in_use
      bits of this bulk are 0, move it to sync_list.
          b. If the number of DEKs, which are freed by users, is over the
      threshold (128), schedule a workqueue to do the sync process.
      
      For the sync process, the SYNC_CRYPTO command is executed first. Then,
      for each bulks in partial_list, full_list and sync_list, reset
      need_sync bits of the freed DEK objects. If all need_sync bits in one
      bulk are zero, move it to avail_list.
      
      We already supported TIS pool to recycle the TISes. With this series
      and TIS pool, TLS CPS performance is improved greatly.
      And we tested https on the system:
          CPU: dual AMD EPYC 7763 64-Core processors
          RAM: 512G
          DEV: ConnectX-6 DX, with FW ver 22.33.0838 and TLS_OPTIMISE=true
      TLS CPS performance numbers are:
          Before: 11k connections/sec
          After: 101 connections/sec
      
      ================
      
      * tag 'mlx5-updates-2023-01-30' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux:
        net/mlx5e: kTLS, Improve connection rate by using fast update encryption key
        net/mlx5: Keep only one bulk of full available DEKs
        net/mlx5: Add async garbage collector for DEK bulk
        net/mlx5: Reuse DEKs after executing SYNC_CRYPTO command
        net/mlx5: Use bulk allocation for fast update encryption key
        net/mlx5: Add bulk allocation and modify_dek operation
        net/mlx5: Add support SYNC_CRYPTO command
        net/mlx5: Add new APIs for fast update encryption key
        net/mlx5: Refactor the encryption key creation
        net/mlx5: Add const to the key pointer of encryption key creation
        net/mlx5: Prepare for fast crypto key update if hardware supports it
        net/mlx5: Change key type to key purpose
        net/mlx5: Add IFC bits and enums for crypto key
        net/mlx5: Add IFC bits for general obj create param
        net/mlx5: Header file for crypto
      ====================
      
      Link: https://lore.kernel.org/r/20230131031201.35336-1-saeed@kernel.org
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      71af6a2d
    • Jakub Kicinski's avatar
      Merge branch '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue · c925ed5f
      Jakub Kicinski authored
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN: Remove redundant Device Control Error Reporting Enable
      
      Bjorn Helgaas says:
      
      Since f26e58bf ("PCI/AER: Enable error reporting when AER is native"),
      the PCI core sets the Device Control bits that enable error reporting for
      PCIe devices.
      
      This series removes redundant calls to pci_enable_pcie_error_reporting()
      that do the same thing from several NIC drivers.
      
      There are several more drivers where this should be removed; I started with
      just the Intel drivers here.
      
      * '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
        ixgbe: Remove redundant pci_enable_pcie_error_reporting()
        igc: Remove redundant pci_enable_pcie_error_reporting()
        igb: Remove redundant pci_enable_pcie_error_reporting()
        ice: Remove redundant pci_enable_pcie_error_reporting()
        iavf: Remove redundant pci_enable_pcie_error_reporting()
        i40e: Remove redundant pci_enable_pcie_error_reporting()
        fm10k: Remove redundant pci_enable_pcie_error_reporting()
        e1000e: Remove redundant pci_enable_pcie_error_reporting()
      ====================
      
      Link: https://lore.kernel.org/r/20230130192519.686446-1-anthony.l.nguyen@intel.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c925ed5f
    • Jakub Kicinski's avatar
      Merge branch 'selftests-mlxsw-convert-to-iproute2-dcb' · 67971c38
      Jakub Kicinski authored
      Petr Machata says:
      
      ====================
      selftests: mlxsw: Convert to iproute2 dcb
      
      There is a dedicated tool for configuration of DCB in iproute2. Use it
      in the selftests instead of lldpad.
      
      Patches #1-#3 convert three tests. Patch #4 drops the now-unnecessary
      lldpad helpers.
      ====================
      
      Link: https://lore.kernel.org/r/cover.1675096231.git.petrm@nvidia.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      67971c38
    • Petr Machata's avatar
      selftests: net: forwarding: lib: Drop lldpad_app_wait_set(), _del() · bd32ff68
      Petr Machata authored
      
      
      The existing users of these helpers have been converted to iproute2 dcb.
      Drop the helpers.
      
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bd32ff68