1. 13 Apr, 2021 7 commits
  2. 12 Apr, 2021 23 commits
  3. 11 Apr, 2021 10 commits
    • David S. Miller's avatar
      Merge branch 'ipa-next' · 5b489fea
      David S. Miller authored
      Alex Elder says:
      
      ====================
      net: ipa: support two more platforms
      
      This series adds IPA support for two more Qualcomm SoCs.
      
      The first patch updates the DT binding to add compatible strings.
      
      The second temporarily disables checksum offload support for IPA
      version 4.5 and above.  Changes are required to the RMNet driver
      to support the "inline" checksum offload used for IPA v4.5+, and
      once those are present this capability will be enabled for IPA.
      
      The third and fourth patches add configuration data for IPA versions
      4.5 (used for the SDX55 SoC) and 4.11 (used for the SD7280 SoC).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b489fea
    • Alex Elder's avatar
      net: ipa: add IPA v4.11 configuration data · 927c5043
      Alex Elder authored
      Add support for the SC7280 SoC, which includes IPA version 4.11.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      927c5043
    • Alex Elder's avatar
      net: ipa: add IPA v4.5 configuration data · fbb763e7
      Alex Elder authored
      Add support for the SDX55 SoC, which includes IPA version 4.5.
      
      Starting with IPA v4.5, a few of the memory regions have a different
      number of "canary" values; update comments in the where the region
      identifers are defined to accurately reflect that.
      
      I'll note three differences in SDX55 versus the other two existing
      platforms (SDM845 and SC7180):
        - SDX55 uses a 32-bit Linux kernel
        - SDX55 has four interconnects rather than three
        - SDX55 uses IPA v4.5, which uses inline checksum offload
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbb763e7
    • Alex Elder's avatar
      net: ipa: disable checksum offload for IPA v4.5+ · c88c34fc
      Alex Elder authored
      Checksum offload for IPA v4.5+ is implemented differently, using
      "inline" offload (which uses a common header format for both upload
      and download offload).
      
      The IPA hardware must be programmed to enable MAP checksum offload,
      but the RMNet driver is responsible for interpreting checksum
      metadata supplied with messages.
      
      Currently, the RMNet driver does not support inline checksum offload.
      This support is imminent, but until it is available, do not allow
      newer versions of IPA to specify checksum offload for endpoints.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c88c34fc
    • Alex Elder's avatar
      dt-bindings: net: qcom,ipa: add some compatible strings · c3264fee
      Alex Elder authored
      Add existing supported platform "qcom,sc7180-ipa" to the set of IPA
      compatible strings.  Also add newly-supported "qcom,sdx55-ipa",
      "qcom,sc7280-ipa".
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3264fee
    • Qiheng Lin's avatar
      ehea: add missing MODULE_DEVICE_TABLE · 95291ced
      Qiheng Lin authored
      This patch adds missing MODULE_DEVICE_TABLE definition which generates
      correct modalias for automatic loading of this driver when it is built
      as an external module.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarQiheng Lin <linqiheng@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95291ced
    • David S. Miller's avatar
      Merge branch 'veth-gro' · 23cfa4d4
      David S. Miller authored
      Paolo Abeni  says:
      
      ====================
      veth: allow GRO even without XDP
      
      This series allows the user-space to enable GRO/NAPI on a veth
      device even without attaching an XDP program.
      
      It does not change the default veth behavior (no NAPI, no GRO),
      except that the GRO feature bit on top of this series will be
      effectively off by default on veth devices. Note that currently
      the GRO bit is on by default, but GRO never takes place in
      absence of XDP.
      
      On top of this series, setting the GRO feature bit enables NAPI
      and allows the GRO to take place. The TSO features on the peer
      device are preserved.
      
      The main goal is improving UDP forwarding performances for
      containers in a typical virtual network setup:
      
      (container) veth -> veth peer -> bridge/ovs -> vxlan -> NIC
      
      Enabling the NAPI threaded mode, GRO the NETIF_F_GRO_UDP_FWD
      feature on the veth peer improves the UDP stream performance
      with not void netfilter configuration by 2x factor with no
      measurable overhead for TCP traffic: some heuristic ensures
      that TCP will not go through the additional NAPI/GRO layer.
      
      Some self-tests are added to check the expected behavior in
      the default configuration, with XDP and with plain GRO enabled.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      23cfa4d4
    • Paolo Abeni's avatar
      self-tests: add veth tests · 1c3cadbe
      Paolo Abeni authored
      Add some basic veth tests, that verify the expected flags and
      aggregation with different setups (default, xdp, etc...)
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c3cadbe
    • Paolo Abeni's avatar
      veth: refine napi usage · 47e550e0
      Paolo Abeni authored
      After the previous patch, when enabling GRO, locally generated
      TCP traffic experiences some measurable overhead, as it traverses
      the GRO engine without any chance of aggregation.
      
      This change refine the NAPI receive path admission test, to avoid
      unnecessary GRO overhead in most scenarios, when GRO is enabled
      on a veth peer.
      
      Only skbs that are eligible for aggregation enter the GRO layer,
      the others will go through the traditional receive path.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47e550e0
    • Paolo Abeni's avatar
      veth: allow enabling NAPI even without XDP · d3256efd
      Paolo Abeni authored
      Currently the veth device has the GRO feature bit set, even if
      no GRO aggregation is possible with the default configuration,
      as the veth device does not hook into the GRO engine.
      
      Flipping the GRO feature bit from user-space is a no-op, unless
      XDP is enabled. In such scenario GRO could actually take place, but
      TSO is forced to off on the peer device.
      
      This change allow user-space to really control the GRO feature, with
      no need for an XDP program.
      
      The GRO feature bit is now cleared by default - so that there are no
      user-visible behavior changes with the default configuration.
      
      When the GRO bit is set, the per-queue NAPI instances are initialized
      and registered. On xmit, when napi instances are available, we try
      to use them.
      
      Some additional checks are in place to ensure we initialize/delete NAPIs
      only when needed in case of overlapping XDP and GRO configuration
      changes.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3256efd