1. 10 Feb, 2022 29 commits
  2. 09 Feb, 2022 11 commits
    • Alexei Starovoitov's avatar
      Merge branch 'Split bpf_sk_lookup remote_port field' · e5313968
      Alexei Starovoitov authored
      Jakub Sitnicki says:
      
      ====================
      
      Following the recent split-up of the bpf_sock dst_port field, apply the same to
      technique to the bpf_sk_lookup remote_port field to make uAPI more user
      friendly.
      
      v1 -> v2:
      - Remove remote_port range check and cast to be16 in TEST_RUN for sk_lookup
        (kernel test robot)
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      e5313968
    • Jakub Sitnicki's avatar
      selftests/bpf: Cover 4-byte load from remote_port in bpf_sk_lookup · 2ed0dc59
      Jakub Sitnicki authored
      Extend the context access tests for sk_lookup prog to cover the surprising
      case of a 4-byte load from the remote_port field, where the expected value
      is actually shifted by 16 bits.
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20220209184333.654927-3-jakub@cloudflare.com
      2ed0dc59
    • Jakub Sitnicki's avatar
      bpf: Make remote_port field in struct bpf_sk_lookup 16-bit wide · 9a69e2b3
      Jakub Sitnicki authored
      remote_port is another case of a BPF context field documented as a 32-bit
      value in network byte order for which the BPF context access converter
      generates a load of a zero-padded 16-bit integer in network byte order.
      
      First such case was dst_port in bpf_sock which got addressed in commit
      4421a582 ("bpf: Make dst_port field in struct bpf_sock 16-bit wide").
      
      Loading 4-bytes from the remote_port offset and converting the value with
      bpf_ntohl() leads to surprising results, as the expected value is shifted
      by 16 bits.
      
      Reduce the confusion by splitting the field in two - a 16-bit field holding
      a big-endian integer, and a 16-bit zero-padding anonymous field that
      follows it.
      Suggested-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20220209184333.654927-2-jakub@cloudflare.com
      9a69e2b3
    • Brett Creeley's avatar
      ice: Add ability for PF admin to enable VF VLAN pruning · f1da5a08
      Brett Creeley authored
      VFs by default are able to see all tagged traffic regardless of trust
      and VLAN filters. Based on legacy devices (i.e. ixgbe, i40e), customers
      expect VFs to receive all VLAN tagged traffic with a matching
      destination MAC.
      
      Add an ethtool private flag 'vf-vlan-pruning' and set the default to
      off so VFs will receive all VLAN traffic directed towards them. When
      the flag is turned on, VF will only be able to receive untagged
      traffic or traffic with VLAN tags it has created interfaces for.
      
      Also, the flag cannot be changed while any VFs are allocated. This was
      done to simplify the implementation. So, if this flag is needed, then
      the PF admin must enable it. If the user tries to enable the flag while
      VFs are active, then print an unsupported message with the
      vf-vlan-pruning flag included. In case multiple flags were specified, this
      makes it clear to the user which flag failed.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarGurucharan G <gurucharanx.g@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      f1da5a08
    • Brett Creeley's avatar
      ice: Add support for 802.1ad port VLANs VF · cbc8b564
      Brett Creeley authored
      Currently there is only support for 802.1Q port VLANs on SR-IOV VFs. Add
      support to also allow 802.1ad port VLANs when double VLAN mode is
      enabled.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      cbc8b564
    • Brett Creeley's avatar
      ice: Advertise 802.1ad VLAN filtering and offloads for PF netdev · 1babaf77
      Brett Creeley authored
      In order for the driver to support 802.1ad VLAN filtering and offloads,
      it needs to advertise those VLAN features and also support modifying
      those VLAN features, so make the necessary changes to
      ice_set_netdev_features(). By default, enable CTAG insertion/stripping
      and CTAG filtering for both Single and Double VLAN Modes (SVM/DVM).
      Also, in DVM, enable STAG filtering by default. This is done by
      setting the feature bits in netdev->features. Also, in DVM, support
      toggling of STAG insertion/stripping, but don't enable them by
      default. This is done by setting the feature bits in
      netdev->hw_features.
      
      Since 802.1ad VLAN filtering and offloads are only supported in DVM, make
      sure they are not enabled by default and that they cannot be enabled
      during runtime, when the device is in SVM.
      
      Add an implementation for the ndo_fix_features() callback. This is
      needed since the hardware cannot support multiple VLAN ethertypes for
      VLAN insertion/stripping simultaneously and all supported VLAN filtering
      must either be enabled or disabled together.
      
      Disable inner VLAN stripping by default when DVM is enabled. If a VSI
      supports stripping the inner VLAN in DVM, then it will have to configure
      that during runtime. For example if a VF is configured in a port VLAN
      while DVM is enabled it will be allowed to offload inner VLANs.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarGurucharan G <gurucharanx.g@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      1babaf77
    • Brett Creeley's avatar
      ice: Support configuring the device to Double VLAN Mode · a1ffafb0
      Brett Creeley authored
      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: default avatarDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: default avatarDan Nowlin <dan.nowlin@intel.com>
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarGurucharan G <gurucharanx.g@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      a1ffafb0
    • Brett Creeley's avatar
      ice: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2 · cc71de8f
      Brett Creeley authored
      Add support for the VF driver to be able to request
      VIRTCHNL_VF_OFFLOAD_VLAN_V2, negotiate its VLAN capabilities via
      VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS, add/delete VLAN filters, and
      enable/disable VLAN offloads.
      
      VFs supporting VIRTCHNL_OFFLOAD_VLAN_V2 will be able to use the
      following virtchnl opcodes:
      
      VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS
      VIRTCHNL_OP_ADD_VLAN_V2
      VIRTCHNL_OP_DEL_VLAN_V2
      VIRTCHNL_OP_ENABLE_VLAN_STRIPPING_V2
      VIRTCHNL_OP_DISABLE_VLAN_STRIPPING_V2
      VIRTCHNL_OP_ENABLE_VLAN_INSERTION_V2
      VIRTCHNL_OP_DISABLE_VLAN_INSERTION_V2
      
      Legacy VF drivers may expect the initial VLAN stripping settings to be
      configured by the PF, so the PF initializes VLAN stripping based on the
      VIRTCHNL_OP_GET_VF_RESOURCES opcode. However, with VLAN support via
      VIRTCHNL_VF_OFFLOAD_VLAN_V2, this function is only expected to be used
      for VFs that only support VIRTCHNL_VF_OFFLOAD_VLAN, which will only
      be supported when a port VLAN is configured. Update the function
      based on the new expectations. Also, change the message when the PF
      can't enable/disable VLAN stripping to a dev_dbg() as this isn't fatal.
      
      When a VF isn't in a port VLAN and it only supports
      VIRTCHNL_VF_OFFLOAD_VLAN when Double VLAN Mode (DVM) is enabled, then
      the PF needs to reject the VIRTCHNL_VF_OFFLOAD_VLAN capability and
      configure the VF in software only VLAN mode. To do this add the new
      function ice_vf_vsi_cfg_legacy_vlan_mode(), which updates the VF's
      inner and outer ice_vsi_vlan_ops functions and sets up software only
      VLAN mode.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      cc71de8f
    • Brett Creeley's avatar
      ice: Add hot path support for 802.1Q and 802.1ad VLAN offloads · 0d54d8f7
      Brett Creeley authored
      Currently the driver only supports 802.1Q VLAN insertion and stripping.
      However, once Double VLAN Mode (DVM) is fully supported, then both 802.1Q
      and 802.1ad VLAN insertion and stripping will be supported. Unfortunately
      the VSI context parameters only allow for one VLAN ethertype at a time
      for VLAN offloads so only one or the other VLAN ethertype offload can be
      supported at once.
      
      To support this, multiple changes are needed.
      
      Rx path changes:
      
      [1] In DVM, the Rx queue context l2tagsel field needs to be cleared so
      the outermost tag shows up in the l2tag2_2nd field of the Rx flex
      descriptor. In Single VLAN Mode (SVM), the l2tagsel field should remain
      1 to support SVM configurations.
      
      [2] Modify the ice_test_staterr() function to take a __le16 instead of
      the ice_32b_rx_flex_desc union pointer so this function can be used for
      both rx_desc->wb.status_error0 and rx_desc->wb.status_error1.
      
      [3] Add the new inline function ice_get_vlan_tag_from_rx_desc() that
      checks if there is a VLAN tag in l2tag1 or l2tag2_2nd.
      
      [4] In ice_receive_skb(), add a check to see if NETIF_F_HW_VLAN_STAG_RX
      is enabled in netdev->features. If it is, then this is the VLAN
      ethertype that needs to be added to the stripping VLAN tag. Since
      ice_fix_features() prevents CTAG_RX and STAG_RX from being enabled
      simultaneously, the VLAN ethertype will only ever be 802.1Q or 802.1ad.
      
      Tx path changes:
      
      [1] In DVM, the VLAN tag needs to be placed in the l2tag2 field of the Tx
      context descriptor. The new define ICE_TX_FLAGS_HW_OUTER_SINGLE_VLAN was
      added to the list of tx_flags to handle this case.
      
      [2] When the stack requests the VLAN tag to be offloaded on Tx, the
      driver needs to set either ICE_TX_FLAGS_HW_OUTER_SINGLE_VLAN or
      ICE_TX_FLAGS_HW_VLAN, so the tag is inserted in l2tag2 or l2tag1
      respectively. To determine which location to use, set a bit in the Tx
      ring flags field during ring allocation that can be used to determine
      which field to use in the Tx descriptor. In DVM, always use l2tag2,
      and in SVM, always use l2tag1.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarGurucharan G <gurucharanx.g@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      0d54d8f7
    • Brett Creeley's avatar
      ice: Add outer_vlan_ops and VSI specific VLAN ops implementations · c31af68a
      Brett Creeley authored
      Add a new outer_vlan_ops member to the ice_vsi structure as outer VLAN
      ops are only available when the device is in Double VLAN Mode (DVM).
      Depending on the VSI type, the requirements for what operations to
      use/allow differ.
      
      By default all VSI's have unsupported inner and outer VSI VLAN ops. This
      implementation was chosen to prevent unexpected crashes due to null
      pointer dereferences. Instead, if a VSI calls an unsupported op, it will
      just return -EOPNOTSUPP.
      
      Add implementations to support modifying outer VLAN fields for VSI
      context. This includes the ability to modify VLAN stripping, insertion,
      and the port VLAN based on the outer VLAN handling fields of the VSI
      context.
      
      These functions should only ever be used if DVM is enabled because that
      means the firmware supports the outer VLAN fields in the VSI context. If
      the device is in DVM, then always use the outer_vlan_ops, else use the
      vlan_ops since the device is in Single VLAN Mode (SVM).
      
      Also, move adding the untagged VLAN 0 filter from ice_vsi_setup() to
      ice_vsi_vlan_setup() as the latter function is specific to the PF and
      all other VSI types that need an untagged VLAN 0 filter already do this
      in their specific flows. Without this change, Flow Director is failing
      to initialize because it does not implement any VSI VLAN ops.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarGurucharan G <gurucharanx.g@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      c31af68a
    • Brett Creeley's avatar
      ice: Adjust naming for inner VLAN operations · 7bd527aa
      Brett Creeley authored
      Current operations act on inner VLAN fields. To support double VLAN, outer
      VLAN operations and functions will be implemented. Add the "inner" naming
      to existing VLAN operations to distinguish them from the upcoming outer
      values and functions. Some spacing adjustments are made to align
      values.
      
      Note that the inner is not talking about a tunneled VLAN, but the second
      VLAN in the packet. For SVM the driver uses inner or single VLAN
      filtering and offloads and in Double VLAN Mode the driver uses the
      inner filtering and offloads for SR-IOV VFs in port VLANs in order to
      support offloading the guest VLAN while a port VLAN is configured.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarGurucharan G <gurucharanx.g@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      7bd527aa