1. 11 Feb, 2022 1 commit
  2. 10 Feb, 2022 30 commits
  3. 09 Feb, 2022 9 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