1. 20 1月, 2023 2 次提交
  2. 27 7月, 2022 1 次提交
    • M
      ice: Add support for PPPoE hardware offload · cd8efeee
      Marcin Szycik 提交于
      Add support for creating PPPoE filters in switchdev mode. Add support
      for parsing PPPoE and PPP-specific tc options: pppoe_sid and ppp_proto.
      
      Example filter:
      tc filter add dev $PF1 ingress protocol ppp_ses prio 1 flower pppoe_sid \
          1234 ppp_proto ip skip_sw action mirred egress redirect dev $VF1_PR
      
      Changes in iproute2 are required to use the new fields.
      
      ICE COMMS DDP package is required to create a filter as it contains PPPoE
      profiles. Added a warning message when loaded DDP package does not contain
      required profiles.
      Signed-off-by: NMarcin Szycik <marcin.szycik@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      cd8efeee
  3. 01 7月, 2022 1 次提交
  4. 15 3月, 2022 1 次提交
    • J
      ice: remove circular header dependencies on ice.h · 649c87c6
      Jacob Keller 提交于
      Several headers in the ice driver include ice.h even though they are
      themselves included by that header. The most notable of these is
      ice_common.h, but several other headers also do this.
      
      Such a recursive inclusion is problematic as it forces headers to be
      included in a strict order, otherwise compilation errors can result. The
      circular inclusions do not trigger an endless loop due to standard
      header inclusion guards, however other errors can occur.
      
      For example, ice_flow.h defines ice_rss_hash_cfg, which is used by
      ice_sriov.h as part of the definition of ice_vf_hash_ip_ctx.
      
      ice_flow.h includes ice_acl.h, which includes ice_common.h, and which
      finally includes ice.h. Since ice.h itself includes ice_sriov.h, this
      creates a circular dependency.
      
      The definition in ice_sriov.h requires things from ice_flow.h, but
      ice_flow.h itself will lead to trying to load ice_sriov.h as part of its
      process for expanding ice.h. The current code avoids this issue by
      having an implicit dependency without the include of ice_flow.h.
      
      If we were to fix that so that ice_sriov.h explicitly depends on
      ice_flow.h the following pattern would occur:
      
        ice_flow.h -> ice_acl.h -> ice_common.h -> ice.h -> ice_sriov.h
      
      At this point, during the expansion of, the header guard for ice_flow.h
      is already set, so when ice_sriov.h attempts to load the ice_flow.h
      header it is skipped. Then, we go on to begin including the rest of
      ice_sriov.h, including structure definitions which depend on
      ice_rss_hash_cfg. This produces a compiler warning because
      ice_rss_hash_cfg hasn't yet been included. Remember, we're just at the
      start of ice_flow.h!
      
      If the order of headers is incorrect (ice_flow.h is not implicitly
      loaded first in all files which include ice_sriov.h) then we get the
      same failure.
      
      Removing this recursive inclusion requires fixing a few cases where some
      headers depended on the header inclusions from ice.h. In addition, a few
      other changes are also required.
      
      Most notably, ice_hw_to_dev is implemented as a macro in ice_osdep.h,
      which is the likely reason that ice_common.h includes ice.h at all. This
      macro implementation requires the full definition of ice_pf in order to
      properly compile.
      
      Fix this by moving it to a function declared in ice_main.c, so that we
      do not require all files to depend on the layout of the ice_pf
      structure.
      
      Note that this change only fixes circular dependencies, but it does not
      fully resolve all implicit dependencies where one header may depend on
      the inclusion of another. I tried to fix as many of the implicit
      dependencies as I noticed, but fixing them all requires a somewhat
      tedious analysis of each header and attempting to compile it separately.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      649c87c6
  5. 12 3月, 2022 2 次提交
  6. 10 2月, 2022 1 次提交
    • B
      ice: Support configuring the device to Double VLAN Mode · a1ffafb0
      Brett Creeley 提交于
      In order to support configuring the device in Double VLAN Mode (DVM),
      the DDP and FW have to support DVM. If both support DVM, the PF that
      downloads the package needs to update the default recipes, set the
      VLAN mode, and update boost TCAM entries.
      
      To support updating the default recipes in DVM, add support for
      updating an existing switch recipe's lkup_idx and mask. This is done
      by first calling the get recipe AQ (0x0292) with the desired recipe
      ID. Then, if that is successful update one of the lookup indices
      (lkup_idx) and its associated mask if the mask is valid otherwise
      the already existing mask will be used.
      
      The VLAN mode of the device has to be configured while the global
      configuration lock is held while downloading the DDP, specifically after
      the DDP has been downloaded. If supported, the device will default to
      DVM.
      Co-developed-by: NDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: NDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NGurucharan G <gurucharanx.g@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      a1ffafb0
  7. 07 1月, 2022 1 次提交
  8. 15 12月, 2021 6 次提交
  9. 08 12月, 2021 1 次提交
  10. 29 10月, 2021 2 次提交
  11. 15 10月, 2021 1 次提交
  12. 11 10月, 2021 2 次提交
    • D
      ice: create advanced switch recipe · fd2a6b71
      Dan Nowlin 提交于
      These changes introduce code for creating advanced recipes for the
      switch in hardware.
      
      There are a couple of recipes already defined in the HW. They apply to
      matching on basic protocol headers, like MAC, VLAN, MACVLAN,
      ethertype or direction (promiscuous), etc.. If the user wants to match on
      other protocol headers (eg. ip address, src/dst port etc.) or different
      variation of already supported protocols, there is a need to create
      new, more complex recipe. That new recipe is referred as
      'advanced recipe', and the filtering rule created on top of that recipe
      is called 'advanced rule'.
      
      One recipe can have up to 5 words, but the first word is always reserved
      for match on switch id, so the driver can define up to 4 words for one
      recipe. To support recipes with more words up to 5 recipes can be
      chained, so 20 words can be programmed for look up.
      
      Input for adding recipe function is a list of protocols to support. Based
      on this list correct profile is being chosen. Correct profile means
      that it contains all protocol types from a list. Each profile have up to
      48 field vector words and each of this word have protocol id and offset.
      These two fields need to match with input data for adding recipe
      function. If the correct profile can't be found the function returns an
      error.
      
      The next step after finding the correct profile is grouping words into
      groups. One group can have up to 4 words. This is done to simplify
      sending recipes to HW (because recipe also can have up to 4 words).
      
      In case of chaining (so when look up consists of more than 4 words) last
      recipe will always have results from the previous recipes used as words.
      
      A recipe to profile map is used to store information about which profile
      is associate with this recipe. This map is an array of 64 elements (max
      number of recipes) and each element is a 256 bits bitmap (max number of
      profiles)
      
      Profile to recipe map is used to store information about which recipe is
      associate with this profile. This map is an array of 256 elements (max
      number of profiles) and each element is a 64 bits bitmap (max number of
      recipes)
      Signed-off-by: NDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: NWojciech Drewek <wojciech.drewek@intel.com>
      Tested-by: NSandeep Penigalapati <sandeep.penigalapati@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      fd2a6b71
    • D
      ice: manage profiles and field vectors · 450052a4
      Dan Nowlin 提交于
      Implement functions to manage profiles and field vectors in hardware.
      
      In hardware, there are up to 256 profiles and each of these profiles can
      have 48 field vector words. Each field vector word is described by
      protocol id and offset in the packet. To add a new recipe all used
      profiles need to be searched. If the profile contains all required
      protocol ids and offsets from the recipe it can be used. The driver has
      to add this profile to recipe association to tell hardware that newly
      added recipe is going to be associated with this profile.
      
      The amount of used profiles depend on the package. To avoid searching
      across not used profile, max profile id value is calculated at init flow.
      The profile is considered as unused when all field vector words in the
      profile are invalid (protocol id 0xff and offset 0x1ff).
      
      Profiles are read from the package section ICE_SID_FLD_VEC_SW. Empty
      field vector words can be used for recipe results. Store all unused field
      vector words in prof_res_bm. It is a 256 elements array (max number of
      profiles) each element is a 48 bit bitmap (max number of field vector
      words).
      
      For now, support only non-tunnel profiles type.
      Co-developed-by: NGrishma Kotecha <grishma.kotecha@intel.com>
      Signed-off-by: NGrishma Kotecha <grishma.kotecha@intel.com>
      Signed-off-by: NDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: NWojciech Drewek <wojciech.drewek@intel.com>
      Tested-by: NSandeep Penigalapati <sandeep.penigalapati@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      450052a4
  13. 15 4月, 2021 1 次提交
  14. 01 4月, 2021 1 次提交
  15. 23 3月, 2021 2 次提交
  16. 09 2月, 2021 1 次提交
  17. 06 2月, 2021 1 次提交
  18. 10 12月, 2020 1 次提交
  19. 10 10月, 2020 1 次提交
  20. 29 9月, 2020 2 次提交
  21. 01 8月, 2020 4 次提交
  22. 02 7月, 2020 1 次提交
  23. 23 5月, 2020 4 次提交