1. 06 5月, 2022 1 次提交
  2. 07 4月, 2022 5 次提交
  3. 17 3月, 2022 1 次提交
  4. 12 3月, 2022 2 次提交
  5. 10 3月, 2022 1 次提交
  6. 19 2月, 2022 1 次提交
  7. 10 2月, 2022 2 次提交
  8. 07 1月, 2022 3 次提交
  9. 15 12月, 2021 3 次提交
  10. 08 12月, 2021 1 次提交
  11. 29 10月, 2021 3 次提交
  12. 21 10月, 2021 1 次提交
    • K
      ice: Add tc-flower filter support for channel · 9fea7498
      Kiran Patil 提交于
      Add support to add/delete channel specific filter using tc-flower.
      For now, only supported action is "skip_sw hw_tc <tc_num>"
      
      Filter criteria is specific to channel and it can be
      combination of L3, L3+L4, L2+L4.
      
      Example:
      MATCH criteria       Action
      ---------------------------
      src and/or dest IPv4[6]/mask -> Forward to "hw_tc <tc_num>"
      dest IPv4[6]/mask + dest L4 port -> Forward to "hw_tc <tc_num>"
      dest MAC + dest L4 port -> Forward to "hw_tc <tc_num>"
      src IPv4[6]/mask + src L4 port -> Forward to "hw_tc <tc_num>"
      src MAC + src L4 port -> Forward to "hw_tc <tc_num>"
      
      Adding tc-flower filter for channel using "hw_tc"
      -------------------------------------------------
      tc qdisc add dev <ethX> clsact
      
      Above two steps are only needed the first time when adding
      tc-flower filter.
      
      tc filter add dev <ethX> protocol ip ingress prio 1 flower \
           dst_ip 192.168.0.1/32 ip_proto tcp dst_port 5001 \
           skip_sw hw_tc 1
      
      tc filter show dev <ethX> ingress
      filter protocol ip pref 1 flower chain 0
      filter protocol ip pref 1 flower chain 0 handle 0x1 hw_tc 1
        eth_type ipv4
        ip_proto tcp
        dst_ip 192.168.0.1
        dst_port 5001
        skip_sw
        in_hw in_hw_count 1
      
      Delete specific filter:
      -------------------------
      tc filter del  dev <ethx> ingress pref 1 handle 0x1 flower
      
      Delete All filters:
      ------------------
      tc filter del dev <ethX> ingress
      Co-developed-by: NAmritha Nambiar <amritha.nambiar@intel.com>
      Signed-off-by: NAmritha Nambiar <amritha.nambiar@intel.com>
      Signed-off-by: NKiran Patil <kiran.patil@intel.com>
      Signed-off-by: NSudheer Mogilappagari <sudheer.mogilappagari@intel.com>
      Tested-by: NBharathi Sreenivas <bharathi.sreenivas@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      9fea7498
  13. 20 10月, 2021 1 次提交
  14. 11 10月, 2021 6 次提交
    • V
      ice: cleanup rules info · 8b8ef05b
      Victor Raj 提交于
      Change ICE_SW_LKUP_LAST to ICE_MAX_NUM_RECIPES as for now there also can
      be recipes other than the default.
      
      Free all structures created for advanced recipes in cleanup function.
      Write a function to clean allocated structures on advanced rule info.
      Signed-off-by: NVictor Raj <victor.raj@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>
      8b8ef05b
    • S
      ice: allow deleting advanced rules · 8bb98f33
      Shivanshu Shukla 提交于
      To remove advanced rule the same protocols list like in adding should be
      send to function. Based on this information list of advanced rules is
      searched to find the correct rule id.
      
      Remove advanced rule if it forwards to only one VSI. If it forwards
      to list of VSI remove only input VSI from this list.
      
      Introduce function to remove rule by id. It is used in case rule needs to
      be removed even if it forwards to the list of VSI.
      
      Allow removing all advanced rules from a particular VSI. It is useful in
      rebuilding VSI path.
      Co-developed-by: NDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: NDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: NShivanshu Shukla <shivanshu.shukla@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>
      8bb98f33
    • G
      ice: allow adding advanced rules · 0f94570d
      Grishma Kotecha 提交于
      Define dummy packet headers to allow adding advanced rules in HW. This
      header is used as admin queue command parameter for adding a rule.
      The firmware will extract correct fields and will use them in look ups.
      
      Define each supported packets header and offsets to words used in recipe.
      Supported headers:
      - MAC + IPv4 + UDP
      - MAC + VLAN + IPv4 + UDP
      - MAC + IPv4 + TCP
      - MAC + VLAN + IPv4 + TCP
      - MAC + IPv6 + UDP
      - MAC + VLAN + IPv6 + UDP
      - MAC + IPv6 + TCP
      - MAC + VLAN + IPv6 + TCP
      
      Add code for creating an advanced rule. Rule needs to match defined
      dummy packet, if not return error, which means that this type of rule
      isn't currently supported.
      
      The first step in adding advanced rule is searching for an advanced
      recipe matching this kind of rule. If it doesn't exist new recipe is
      created. Dummy packet has to be filled with the correct header field
      value from the rule definition. It will be used to do look up in HW.
      
      Support searching for existing advance rule entry. It is used in case
      of adding the same rule on different VSI. In this case, instead of
      creating new rule, the existing one should be updated with refreshed VSI
      list.
      
      Add initialization for prof_res_bm_init flag to zero so that
      the possible resource for fv in the files can be initialized.
      Co-developed-by: NDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: NDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: NGrishma Kotecha <grishma.kotecha@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>
      0f94570d
    • 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
    • G
      ice: implement low level recipes functions · 7715ec32
      Grishma Kotecha 提交于
      Add code to manage recipes and profiles on admin queue layer.
      
      Allow the driver to add a new recipe and update an existing one. Get a
      recipe and get a recipe to profile association is mostly used in update
      existing recipes code.
      
      Only default recipes can be updated. An update is done by reading recipes
      from HW, changing their params and calling add recipe command.
      
      Support following admin queue commands:
      - ice_aqc_opc_add_recipe (0x0290) - create a recipe with protocol
      header information and other details that determine how this recipe
      filter works
      - ice_aqc_opc_recipe_to_profile (0x0291) - associate a switch recipe
      to a profile
      - ice_aqc_opc_get_recipe (0x0292) - get details of an existing recipe
      - ice_aqc_opc_get_recipe_to_profile (0x0293) - get a recipe associated
      with profile ID
      
      Define ICE_AQC_RES_TYPE_RECIPE resource type to hold a switch
      recipe. It is needed when a new switch recipe needs to be created.
      Co-developed-by: NDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: NDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: NGrishma Kotecha  <grishma.kotecha@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>
      7715ec32
  15. 08 10月, 2021 1 次提交
  16. 29 5月, 2021 1 次提交
  17. 01 4月, 2021 1 次提交
  18. 30 3月, 2021 2 次提交
  19. 09 2月, 2021 1 次提交
  20. 10 12月, 2020 1 次提交
  21. 29 7月, 2020 1 次提交
  22. 02 7月, 2020 1 次提交