1. 12 1月, 2022 2 次提交
  2. 18 11月, 2021 4 次提交
  3. 28 9月, 2021 4 次提交
  4. 26 9月, 2021 2 次提交
  5. 02 9月, 2021 1 次提交
  6. 26 7月, 2021 21 次提交
  7. 17 7月, 2021 4 次提交
  8. 16 7月, 2021 2 次提交
    • G
      net: hns3: refine the VLAN tag handle for port based VLAN · fd9b7335
      Guojia Liao 提交于
      mainline inclusion
      from mainline-v5.11-rc1
      commit 592b0179
      category: feature
      bugzilla: 173966
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=592b0179cd498641ae45b9ad4276f5038230f7aa
      
      ----------------------------------------------------------------------
      
      For DEVICE_VERSION_V2, the hardware only supports max two layer
      VLAN tags, including port based tag inserted by hardware, tag in
      tx buffer descriptor(get from skb->tci) and tag in packet.
      
      For transmit packet:
      If port based VLAN disabled, and vf driver gets a VLAN tag from
      skb, the VLAN tag must be filled to the Outer_VLAN_TAG field
      (tag near to DMAC) of tx buffer descriptor, otherwise it may
      be inserted after the tag in packet.
      
      If port based VLAN enabled, and vf driver gets a VLAN tag from
      skb, the VLAN tag must be filled to the VLAN_TAG field (tag
      far to DMAC) of tx buffer descriptor, otherwise it may be
      conflicted with port based VLAN, and raise a hardware error.
      
      For receive packet:
      The hardware will strip the VLAN tags and fill them in the rx
      buffer descriptor, no matter port based VLAN enable or not.
      Because port based VLAN tag is useless for stack, so vf driver
      needs to discard the port based VLAN tag get from rx buffer
      descriptor when port based VLAN enabled.
      
      So vf must know about the port based VLAN state.
      
      For DEVICE_VERSION_V3, the hardware provides some new
      configuration to improve it.
      
      For transmit packet:
      When enable tag shift mode, hardware will handle the VLAN tag
      in outer_VLAN_TAG field as VLAN_TAG, so it won't conflict with
      port based VLAN. And hardware also make sure the tag before
      the tag in packet. So vf driver doesn't need to specify the tag
      position according to the port based VLAN state anymore.
      
      For receive packet:
      When enable discard mode, hardware will strip and discard the
      port based VLAN tag, so vf driver doesn't need to identify it
      from rx buffer descriptor.
      
      So modify the port based VLAN configuration, simplify the process
      for vf handling the VLAN tag.
      Signed-off-by: NGuojia Liao <liaoguojia@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NYongxin Li <liyongxin1@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      fd9b7335
    • G
      net: hns3: add support for extended promiscuous command · 567d6b5a
      Guojia Liao 提交于
      mainline inclusion
      from mainline-v5.11-rc1
      commit c43abe1a
      category: feature
      bugzilla: 173966
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c43abe1a5f83d3afe39f9aea99edfd594add705c
      
      ----------------------------------------------------------------------
      
      For DEVICE_VERSION_V2, the hardware supports enable tx and rx
      promiscuous separately. But tx or rx promiscuous is active for
      unicast, multicast and broadcast promiscuous simultaneously.
      To support traffics between functions belong to the same port,
      we always enable tx promiscuous for broadcast promiscuous, so
      tx promiscuous for unicast and multicast promiscuous is also
      enabled.
      
      For DEVICE_VERSION_V3, the hardware decouples the above
      relationship. Tx unicast promiscuous, rx unicast promiscuous,
      tx multicast promiscuous, rx multicast promiscuous, tx broadcast
      promiscuous and rx broadcast promiscuous can be enabled separately.
      
      So add support for the new promiscuous command.
      Signed-off-by: NGuojia Liao <liaoguojia@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NYongxin Li <liyongxin1@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      567d6b5a