linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API
@ 2022-08-17 14:35 Guangbin Huang
  2022-08-17 14:35 ` [PATCH net-next 1/2] net: ethtool: " Guangbin Huang
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Guangbin Huang @ 2022-08-17 14:35 UTC (permalink / raw)
  To: davem, kuba, idosch, linux, mkubecek
  Cc: netdev, linux-kernel, lipeng321, shenjian15, huangguangbin2

This series adds support for steering VxLAN flows using the ethtool NFC
interface, and implements it for hns3 devices.

Guangbin Huang (2):
  net: ethtool: add VxLAN to the NFC API
  net: hns3: support set/get VxLAN rule of rx flow director by ethtool

 .../hisilicon/hns3/hns3pf/hclge_main.c        | 272 +++++++++++++++++-
 .../hisilicon/hns3/hns3pf/hclge_main.h        |   2 +
 include/uapi/linux/ethtool.h                  |  48 ++++
 3 files changed, 319 insertions(+), 3 deletions(-)

-- 
2.33.0


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH net-next 1/2] net: ethtool: add VxLAN to the NFC API
  2022-08-17 14:35 [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API Guangbin Huang
@ 2022-08-17 14:35 ` Guangbin Huang
  2022-08-17 14:35 ` [PATCH net-next 2/2] net: hns3: support set/get VxLAN rule of rx flow director by ethtool Guangbin Huang
  2022-08-17 18:16 ` [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API Jakub Kicinski
  2 siblings, 0 replies; 8+ messages in thread
From: Guangbin Huang @ 2022-08-17 14:35 UTC (permalink / raw)
  To: davem, kuba, idosch, linux, mkubecek
  Cc: netdev, linux-kernel, lipeng321, shenjian15, huangguangbin2

To support for steering VxLAN flows using the ethtool NFC interface, this
patch adds flow specifications for vxlan4(VxLAN with inner IPv4) and vxlan6
(VxLAN with inner IPv6).

Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
---
 include/uapi/linux/ethtool.h | 48 ++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 2d5741fd44bb..687c4b5e7bc6 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -931,6 +931,28 @@ struct ethtool_usrip4_spec {
 	__u8    proto;
 };
 
+/**
+ * struct ethtool_vxlan4_spec - general flow specification for VxLAN IPv4
+ * @vni: VxLAN network identifier
+ * @dst: Inner destination eth addr
+ * @src: Inner source eth addr
+ * @eth_type: Inner ethernet type
+ * @tos: Inner type-of-service
+ * @l4_proto: Inner transport protocol number
+ * @ip4src: Inner source host
+ * @ip4dst: Inner destination host
+ */
+struct ethtool_vxlan4_spec {
+	__be32	vni;
+	__u8	dst[ETH_ALEN];
+	__u8	src[ETH_ALEN];
+	__be16	eth_type;
+	__u8	tos;
+	__u8	l4_proto;
+	__be32	ip4src;
+	__be32	ip4dst;
+};
+
 /**
  * struct ethtool_tcpip6_spec - flow specification for TCP/IPv6 etc.
  * @ip6src: Source host
@@ -981,6 +1003,28 @@ struct ethtool_usrip6_spec {
 	__u8    l4_proto;
 };
 
+/**
+ * struct ethtool_vxlan6_spec - general flow specification for VxLAN IPv6
+ * @vni: VxLAN network identifier
+ * @dst: Inner destination eth addr
+ * @src: Inner source eth addr
+ * @eth_type: Inner ethernet type
+ * @tclass: Inner traffic Class
+ * @l4_proto: Inner transport protocol number
+ * @ip6src: Inner source host
+ * @ip6dst: Inner destination host
+ */
+struct ethtool_vxlan6_spec {
+	__be32	vni;
+	__u8	dst[ETH_ALEN];
+	__u8	src[ETH_ALEN];
+	__be16	eth_type;
+	__u8	tclass;
+	__u8	l4_proto;
+	__be32	ip6src[4];
+	__be32	ip6dst[4];
+};
+
 union ethtool_flow_union {
 	struct ethtool_tcpip4_spec		tcp_ip4_spec;
 	struct ethtool_tcpip4_spec		udp_ip4_spec;
@@ -988,12 +1032,14 @@ union ethtool_flow_union {
 	struct ethtool_ah_espip4_spec		ah_ip4_spec;
 	struct ethtool_ah_espip4_spec		esp_ip4_spec;
 	struct ethtool_usrip4_spec		usr_ip4_spec;
+	struct ethtool_vxlan4_spec		vxlan_ip4_spec;
 	struct ethtool_tcpip6_spec		tcp_ip6_spec;
 	struct ethtool_tcpip6_spec		udp_ip6_spec;
 	struct ethtool_tcpip6_spec		sctp_ip6_spec;
 	struct ethtool_ah_espip6_spec		ah_ip6_spec;
 	struct ethtool_ah_espip6_spec		esp_ip6_spec;
 	struct ethtool_usrip6_spec		usr_ip6_spec;
+	struct ethtool_vxlan6_spec		vxlan_ip6_spec;
 	struct ethhdr				ether_spec;
 	__u8					hdata[52];
 };
@@ -1900,6 +1946,8 @@ static inline int ethtool_validate_duplex(__u8 duplex)
 #define	IPV4_FLOW	0x10	/* hash only */
 #define	IPV6_FLOW	0x11	/* hash only */
 #define	ETHER_FLOW	0x12	/* spec only (ether_spec) */
+#define	VXLAN_V4_FLOW	0x13	/* spec only (vxlan_ip4_spec) */
+#define	VXLAN_V6_FLOW	0x14	/* spec only (vxlan_ip6_spec) */
 /* Flag to enable additional fields in struct ethtool_rx_flow_spec */
 #define	FLOW_EXT	0x80000000
 #define	FLOW_MAC_EXT	0x40000000
-- 
2.33.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH net-next 2/2] net: hns3: support set/get VxLAN rule of rx flow director by ethtool
  2022-08-17 14:35 [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API Guangbin Huang
  2022-08-17 14:35 ` [PATCH net-next 1/2] net: ethtool: " Guangbin Huang
@ 2022-08-17 14:35 ` Guangbin Huang
  2022-08-17 18:16 ` [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API Jakub Kicinski
  2 siblings, 0 replies; 8+ messages in thread
From: Guangbin Huang @ 2022-08-17 14:35 UTC (permalink / raw)
  To: davem, kuba, idosch, linux, mkubecek
  Cc: netdev, linux-kernel, lipeng321, shenjian15, huangguangbin2

This patch adds support rule type of vxlan4 and vxlan6 for rx flow
director by command ethtool -u/-U.

Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
---
 .../hisilicon/hns3/hns3pf/hclge_main.c        | 272 +++++++++++++++++-
 .../hisilicon/hns3/hns3pf/hclge_main.h        |   2 +
 2 files changed, 271 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index fae79764dc44..ed4e6732a287 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -15,6 +15,7 @@
 #include <linux/crash_dump.h>
 #include <net/ipv6.h>
 #include <net/rtnetlink.h>
+#include <net/vxlan.h>
 #include "hclge_cmd.h"
 #include "hclge_dcb.h"
 #include "hclge_main.h"
@@ -427,7 +428,9 @@ static const struct key_info tuple_key_info[] = {
 	{ OUTER_SRC_PORT, 16, KEY_OPT_LE16, -1, -1 },
 	{ OUTER_DST_PORT, 16, KEY_OPT_LE16, -1, -1 },
 	{ OUTER_L4_RSV, 32, KEY_OPT_LE32, -1, -1 },
-	{ OUTER_TUN_VNI, 24, KEY_OPT_VNI, -1, -1 },
+	{ OUTER_TUN_VNI, 24, KEY_OPT_VNI,
+	  offsetof(struct hclge_fd_rule, tuples.outer_tun_vni),
+	  offsetof(struct hclge_fd_rule, tuples_mask.outer_tun_vni) },
 	{ OUTER_TUN_FLOW_ID, 8, KEY_OPT_U8, -1, -1 },
 	{ INNER_DST_MAC, 48, KEY_OPT_MAC,
 	  offsetof(struct hclge_fd_rule, tuples.dst_mac),
@@ -5369,8 +5372,9 @@ static int hclge_init_fd_config(struct hclge_dev *hdev)
 
 	/* If use max 400bit key, we can support tuples for ether type */
 	if (hdev->fd_cfg.fd_mode == HCLGE_FD_MODE_DEPTH_2K_WIDTH_400B_STAGE_1) {
-		key_cfg->tuple_active |=
-				BIT(INNER_DST_MAC) | BIT(INNER_SRC_MAC);
+		key_cfg->tuple_active |= BIT(INNER_DST_MAC) |
+					 BIT(INNER_SRC_MAC) |
+					 BIT(OUTER_TUN_VNI);
 		if (hdev->ae_dev->dev_version >= HNAE3_DEVICE_VERSION_V3)
 			key_cfg->tuple_active |= HCLGE_FD_TUPLE_USER_DEF_TUPLES;
 	}
@@ -5482,6 +5486,8 @@ static int hclge_fd_ad_config(struct hclge_dev *hdev, u8 stage, int loc,
 static bool hclge_fd_convert_tuple(u32 tuple_bit, u8 *key_x, u8 *key_y,
 				   struct hclge_fd_rule *rule)
 {
+#define HCLGE_VNI_LENGTH	3
+
 	int offset, moffset, ip_offset;
 	enum HCLGE_FD_KEY_OPT key_opt;
 	u16 tmp_x_s, tmp_y_s;
@@ -5534,6 +5540,14 @@ static bool hclge_fd_convert_tuple(u32 tuple_bit, u8 *key_x, u8 *key_y,
 		*(__le32 *)key_x = cpu_to_le32(tmp_x_l);
 		*(__le32 *)key_y = cpu_to_le32(tmp_y_l);
 
+		return true;
+	case KEY_OPT_VNI:
+		calc_x(tmp_x_l, *(u32 *)(&p[offset]), *(u32 *)(&p[moffset]));
+		calc_y(tmp_y_l, *(u32 *)(&p[offset]), *(u32 *)(&p[moffset]));
+		for (i = 0; i < HCLGE_VNI_LENGTH; i++) {
+			key_x[i] = (cpu_to_le32(tmp_x_l) >> (i * BITS_PER_BYTE)) & 0xFF;
+			key_y[i] = (cpu_to_le32(tmp_y_l) >> (i * BITS_PER_BYTE)) & 0xFF;
+		}
 		return true;
 	default:
 		return false;
@@ -5756,6 +5770,45 @@ static int hclge_fd_check_ip4_tuple(struct ethtool_usrip4_spec *spec,
 	return 0;
 }
 
+static int hclge_fd_check_vxlan4_tuple(struct ethtool_rx_flow_spec *fs,
+				       u32 *unused_tuple)
+{
+	struct ethtool_vxlan4_spec *spec = &fs->h_u.vxlan_ip4_spec;
+	struct ethtool_vxlan4_spec *mask = &fs->m_u.vxlan_ip4_spec;
+
+	/* Vni is only 24 bits and must be greater than 0, and it can not be
+	 * masked.
+	 */
+	if (!spec->vni || be32_to_cpu(spec->vni) >= VXLAN_N_VID ||
+	    mask->vni != HCLGE_FD_VXLAN_VNI_UNMASK || !unused_tuple)
+		return -EINVAL;
+
+	*unused_tuple |= BIT(INNER_SRC_PORT) | BIT(INNER_DST_PORT);
+
+	if (is_zero_ether_addr(spec->src))
+		*unused_tuple |= BIT(INNER_SRC_MAC);
+
+	if (is_zero_ether_addr(spec->dst))
+		*unused_tuple |= BIT(INNER_DST_MAC);
+
+	if (!spec->eth_type)
+		*unused_tuple |= BIT(INNER_ETH_TYPE);
+
+	if (!spec->ip4src)
+		*unused_tuple |= BIT(INNER_SRC_IP);
+
+	if (!spec->ip4dst)
+		*unused_tuple |= BIT(INNER_DST_IP);
+
+	if (!spec->tos)
+		*unused_tuple |= BIT(INNER_IP_TOS);
+
+	if (!spec->l4_proto)
+		*unused_tuple |= BIT(INNER_IP_PROTO);
+
+	return 0;
+}
+
 static int hclge_fd_check_tcpip6_tuple(struct ethtool_tcpip6_spec *spec,
 				       u32 *unused_tuple)
 {
@@ -5811,6 +5864,45 @@ static int hclge_fd_check_ip6_tuple(struct ethtool_usrip6_spec *spec,
 	return 0;
 }
 
+static int hclge_fd_check_vxlan6_tuple(struct ethtool_rx_flow_spec *fs,
+				       u32 *unused_tuple)
+{
+	struct ethtool_vxlan6_spec *spec = &fs->h_u.vxlan_ip6_spec;
+	struct ethtool_vxlan6_spec *mask = &fs->m_u.vxlan_ip6_spec;
+
+	/* Vni is only 24 bits and must be greater than 0, and it can not be
+	 * masked.
+	 */
+	if (!spec->vni || be32_to_cpu(spec->vni) >= VXLAN_N_VID ||
+	    mask->vni != HCLGE_FD_VXLAN_VNI_UNMASK || !unused_tuple)
+		return -EINVAL;
+
+	*unused_tuple |= BIT(INNER_SRC_PORT) | BIT(INNER_DST_PORT);
+
+	if (is_zero_ether_addr(spec->src))
+		*unused_tuple |= BIT(INNER_SRC_MAC);
+
+	if (is_zero_ether_addr(spec->dst))
+		*unused_tuple |= BIT(INNER_DST_MAC);
+
+	if (!spec->eth_type)
+		*unused_tuple |= BIT(INNER_ETH_TYPE);
+
+	if (ipv6_addr_any((struct in6_addr *)spec->ip6src))
+		*unused_tuple |= BIT(INNER_SRC_IP);
+
+	if (ipv6_addr_any((struct in6_addr *)spec->ip6dst))
+		*unused_tuple |= BIT(INNER_DST_IP);
+
+	if (!spec->tclass)
+		*unused_tuple |= BIT(INNER_IP_TOS);
+
+	if (!spec->l4_proto)
+		*unused_tuple |= BIT(INNER_IP_PROTO);
+
+	return 0;
+}
+
 static int hclge_fd_check_ether_tuple(struct ethhdr *spec, u32 *unused_tuple)
 {
 	if (!spec || !unused_tuple)
@@ -5993,6 +6085,9 @@ static int hclge_fd_check_spec(struct hclge_dev *hdev,
 		ret = hclge_fd_check_ip4_tuple(&fs->h_u.usr_ip4_spec,
 					       unused_tuple);
 		break;
+	case VXLAN_V4_FLOW:
+		ret = hclge_fd_check_vxlan4_tuple(fs, unused_tuple);
+		break;
 	case SCTP_V6_FLOW:
 	case TCP_V6_FLOW:
 	case UDP_V6_FLOW:
@@ -6003,6 +6098,9 @@ static int hclge_fd_check_spec(struct hclge_dev *hdev,
 		ret = hclge_fd_check_ip6_tuple(&fs->h_u.usr_ip6_spec,
 					       unused_tuple);
 		break;
+	case VXLAN_V6_FLOW:
+		ret = hclge_fd_check_vxlan6_tuple(fs, unused_tuple);
+		break;
 	case ETHER_FLOW:
 		if (hdev->fd_cfg.fd_mode !=
 			HCLGE_FD_MODE_DEPTH_2K_WIDTH_400B_STAGE_1) {
@@ -6085,6 +6183,37 @@ static void hclge_fd_get_ip4_tuple(struct hclge_dev *hdev,
 	rule->tuples_mask.ether_proto = 0xFFFF;
 }
 
+static void hclge_fd_get_vxlan4_tuple(struct ethtool_rx_flow_spec *fs,
+				      struct hclge_fd_rule *rule)
+{
+	struct ethtool_vxlan4_spec *h = &fs->h_u.vxlan_ip4_spec;
+	struct ethtool_vxlan4_spec *m = &fs->m_u.vxlan_ip4_spec;
+
+	rule->tuples.outer_tun_vni = be32_to_cpu(h->vni);
+	rule->tuples_mask.outer_tun_vni = be32_to_cpu(m->vni);
+
+	ether_addr_copy(rule->tuples.src_mac, h->src);
+	ether_addr_copy(rule->tuples_mask.src_mac, m->src);
+
+	ether_addr_copy(rule->tuples.dst_mac, h->dst);
+	ether_addr_copy(rule->tuples_mask.dst_mac, m->dst);
+
+	rule->tuples.ether_proto = be16_to_cpu(h->eth_type);
+	rule->tuples_mask.ether_proto = be16_to_cpu(m->eth_type);
+
+	rule->tuples.ip_tos = h->tos;
+	rule->tuples_mask.ip_tos = m->tos;
+
+	rule->tuples.ip_proto = h->l4_proto;
+	rule->tuples_mask.ip_proto = m->l4_proto;
+
+	rule->tuples.src_ip[IPV4_INDEX] = be32_to_cpu(h->ip4src);
+	rule->tuples_mask.src_ip[IPV4_INDEX] = be32_to_cpu(m->ip4src);
+
+	rule->tuples.dst_ip[IPV4_INDEX] = be32_to_cpu(h->ip4dst);
+	rule->tuples_mask.dst_ip[IPV4_INDEX] = be32_to_cpu(m->ip4dst);
+}
+
 static void hclge_fd_get_tcpip6_tuple(struct hclge_dev *hdev,
 				      struct ethtool_rx_flow_spec *fs,
 				      struct hclge_fd_rule *rule, u8 ip_proto)
@@ -6139,6 +6268,37 @@ static void hclge_fd_get_ip6_tuple(struct hclge_dev *hdev,
 	rule->tuples_mask.ether_proto = 0xFFFF;
 }
 
+static void hclge_fd_get_vxlan6_tuple(struct ethtool_rx_flow_spec *fs,
+				      struct hclge_fd_rule *rule)
+{
+	struct ethtool_vxlan6_spec *h = &fs->h_u.vxlan_ip6_spec;
+	struct ethtool_vxlan6_spec *m = &fs->m_u.vxlan_ip6_spec;
+
+	rule->tuples.outer_tun_vni = be32_to_cpu(h->vni);
+	rule->tuples_mask.outer_tun_vni = be32_to_cpu(m->vni);
+
+	ether_addr_copy(rule->tuples.src_mac, h->src);
+	ether_addr_copy(rule->tuples_mask.src_mac, m->src);
+
+	ether_addr_copy(rule->tuples.dst_mac, h->dst);
+	ether_addr_copy(rule->tuples_mask.dst_mac, m->dst);
+
+	rule->tuples.ether_proto = be16_to_cpu(h->eth_type);
+	rule->tuples_mask.ether_proto = be16_to_cpu(m->eth_type);
+
+	rule->tuples.ip_tos = h->tclass;
+	rule->tuples_mask.ip_tos = m->tclass;
+
+	rule->tuples.ip_proto = h->l4_proto;
+	rule->tuples_mask.ip_proto = m->l4_proto;
+
+	be32_to_cpu_array(rule->tuples.src_ip, h->ip6src, IPV6_SIZE);
+	be32_to_cpu_array(rule->tuples_mask.src_ip, m->ip6src, IPV6_SIZE);
+
+	be32_to_cpu_array(rule->tuples.dst_ip, h->ip6dst, IPV6_SIZE);
+	be32_to_cpu_array(rule->tuples_mask.dst_ip, m->ip6dst, IPV6_SIZE);
+}
+
 static void hclge_fd_get_ether_tuple(struct hclge_dev *hdev,
 				     struct ethtool_rx_flow_spec *fs,
 				     struct hclge_fd_rule *rule)
@@ -6196,6 +6356,9 @@ static int hclge_fd_get_tuple(struct hclge_dev *hdev,
 	case IP_USER_FLOW:
 		hclge_fd_get_ip4_tuple(hdev, fs, rule);
 		break;
+	case VXLAN_V4_FLOW:
+		hclge_fd_get_vxlan4_tuple(fs, rule);
+		break;
 	case SCTP_V6_FLOW:
 		hclge_fd_get_tcpip6_tuple(hdev, fs, rule, IPPROTO_SCTP);
 		break;
@@ -6208,6 +6371,9 @@ static int hclge_fd_get_tuple(struct hclge_dev *hdev,
 	case IPV6_USER_FLOW:
 		hclge_fd_get_ip6_tuple(hdev, fs, rule);
 		break;
+	case VXLAN_V6_FLOW:
+		hclge_fd_get_vxlan6_tuple(fs, rule);
+		break;
 	case ETHER_FLOW:
 		hclge_fd_get_ether_tuple(hdev, fs, rule);
 		break;
@@ -6554,6 +6720,48 @@ static void hclge_fd_get_ip4_info(struct hclge_fd_rule *rule,
 	spec->ip_ver = ETH_RX_NFC_IP4;
 }
 
+static void hclge_fd_get_vxlan4_info(struct hclge_fd_rule *rule,
+				     struct ethtool_vxlan4_spec *spec,
+				     struct ethtool_vxlan4_spec *spec_mask)
+{
+	spec->vni = cpu_to_be32(rule->tuples.outer_tun_vni);
+	spec_mask->vni = rule->unused_tuple & BIT(OUTER_TUN_VNI) ? 0 :
+			 cpu_to_be32(rule->tuples_mask.outer_tun_vni);
+
+	ether_addr_copy(spec->src, rule->tuples.src_mac);
+	ether_addr_copy(spec->dst, rule->tuples.dst_mac);
+
+	if (rule->unused_tuple & BIT(INNER_SRC_MAC))
+		eth_zero_addr(spec_mask->src);
+	else
+		ether_addr_copy(spec_mask->src, rule->tuples_mask.src_mac);
+
+	if (rule->unused_tuple & BIT(INNER_DST_MAC))
+		eth_zero_addr(spec_mask->dst);
+	else
+		ether_addr_copy(spec_mask->dst, rule->tuples_mask.dst_mac);
+
+	spec->eth_type = cpu_to_be16(rule->tuples.ether_proto);
+	spec_mask->eth_type = rule->unused_tuple & BIT(INNER_ETH_TYPE) ? 0 :
+			     cpu_to_be16(rule->tuples_mask.ether_proto);
+
+	spec->tos = rule->tuples.ip_tos;
+	spec_mask->tos = rule->unused_tuple & BIT(INNER_IP_TOS) ? 0 :
+			 rule->tuples_mask.ip_tos;
+
+	spec->l4_proto = rule->tuples.ip_proto;
+	spec_mask->l4_proto = rule->unused_tuple & BIT(INNER_IP_PROTO) ? 0 :
+			     rule->tuples_mask.ip_proto;
+
+	spec->ip4src = cpu_to_be32(rule->tuples.src_ip[IPV4_INDEX]);
+	spec_mask->ip4src = rule->unused_tuple & BIT(INNER_SRC_IP) ? 0 :
+			    cpu_to_be32(rule->tuples_mask.src_ip[IPV4_INDEX]);
+
+	spec->ip4dst = cpu_to_be32(rule->tuples.dst_ip[IPV4_INDEX]);
+	spec_mask->ip4dst = rule->unused_tuple & BIT(INNER_DST_IP) ? 0 :
+			    cpu_to_be32(rule->tuples_mask.dst_ip[IPV4_INDEX]);
+}
+
 static void hclge_fd_get_tcpip6_info(struct hclge_fd_rule *rule,
 				     struct ethtool_tcpip6_spec *spec,
 				     struct ethtool_tcpip6_spec *spec_mask)
@@ -6614,6 +6822,56 @@ static void hclge_fd_get_ip6_info(struct hclge_fd_rule *rule,
 			0 : rule->tuples_mask.ip_proto;
 }
 
+static void hclge_fd_get_vxlan6_info(struct hclge_fd_rule *rule,
+				     struct ethtool_vxlan6_spec *spec,
+				     struct ethtool_vxlan6_spec *spec_mask)
+{
+	spec->vni = cpu_to_be32(rule->tuples.outer_tun_vni);
+	spec_mask->vni = rule->unused_tuple & BIT(OUTER_TUN_VNI) ? 0 :
+			 cpu_to_be32(rule->tuples_mask.outer_tun_vni);
+
+	ether_addr_copy(spec->src, rule->tuples.src_mac);
+	ether_addr_copy(spec->dst, rule->tuples.dst_mac);
+
+	if (rule->unused_tuple & BIT(INNER_SRC_MAC))
+		eth_zero_addr(spec_mask->src);
+	else
+		ether_addr_copy(spec_mask->src, rule->tuples_mask.src_mac);
+
+	if (rule->unused_tuple & BIT(INNER_DST_MAC))
+		eth_zero_addr(spec_mask->dst);
+	else
+		ether_addr_copy(spec_mask->dst, rule->tuples_mask.dst_mac);
+
+	spec->eth_type = cpu_to_be16(rule->tuples.ether_proto);
+	spec_mask->eth_type = rule->unused_tuple & BIT(INNER_ETH_TYPE) ? 0 :
+			     cpu_to_be16(rule->tuples_mask.ether_proto);
+
+	spec->tclass = rule->tuples.ip_tos;
+	spec_mask->tclass = rule->unused_tuple & BIT(INNER_IP_TOS) ? 0 :
+			    rule->tuples_mask.ip_tos;
+
+	spec->l4_proto = rule->tuples.ip_proto;
+	spec_mask->l4_proto = rule->unused_tuple & BIT(INNER_IP_PROTO) ? 0 :
+			     rule->tuples_mask.ip_proto;
+
+	cpu_to_be32_array(spec->ip6src,
+			  rule->tuples.src_ip, IPV6_SIZE);
+	cpu_to_be32_array(spec->ip6dst,
+			  rule->tuples.dst_ip, IPV6_SIZE);
+	if (rule->unused_tuple & BIT(INNER_SRC_IP))
+		memset(spec_mask->ip6src, 0, sizeof(spec_mask->ip6src));
+	else
+		cpu_to_be32_array(spec_mask->ip6src, rule->tuples_mask.src_ip,
+				  IPV6_SIZE);
+
+	if (rule->unused_tuple & BIT(INNER_DST_IP))
+		memset(spec_mask->ip6dst, 0, sizeof(spec_mask->ip6dst));
+	else
+		cpu_to_be32_array(spec_mask->ip6dst, rule->tuples_mask.dst_ip,
+				  IPV6_SIZE);
+}
+
 static void hclge_fd_get_ether_info(struct hclge_fd_rule *rule,
 				    struct ethhdr *spec,
 				    struct ethhdr *spec_mask)
@@ -6740,6 +6998,10 @@ static int hclge_get_fd_rule_info(struct hnae3_handle *handle,
 		hclge_fd_get_ip4_info(rule, &fs->h_u.usr_ip4_spec,
 				      &fs->m_u.usr_ip4_spec);
 		break;
+	case VXLAN_V4_FLOW:
+		hclge_fd_get_vxlan4_info(rule, &fs->h_u.vxlan_ip4_spec,
+					 &fs->m_u.vxlan_ip4_spec);
+		break;
 	case SCTP_V6_FLOW:
 	case TCP_V6_FLOW:
 	case UDP_V6_FLOW:
@@ -6750,6 +7012,10 @@ static int hclge_get_fd_rule_info(struct hnae3_handle *handle,
 		hclge_fd_get_ip6_info(rule, &fs->h_u.usr_ip6_spec,
 				      &fs->m_u.usr_ip6_spec);
 		break;
+	case VXLAN_V6_FLOW:
+		hclge_fd_get_vxlan6_info(rule, &fs->h_u.vxlan_ip6_spec,
+					 &fs->m_u.vxlan_ip6_spec);
+		break;
 	/* The flow type of fd rule has been checked before adding in to rule
 	 * list. As other flow types have been handled, it must be ETHER_FLOW
 	 * for the default case
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index 18caddd541f8..db1681709868 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -594,6 +594,7 @@ struct key_info {
 #define HCLGE_FD_USER_DEF_DATA		GENMASK(15, 0)
 #define HCLGE_FD_USER_DEF_OFFSET	GENMASK(15, 0)
 #define HCLGE_FD_USER_DEF_OFFSET_UNMASK	GENMASK(15, 0)
+#define HCLGE_FD_VXLAN_VNI_UNMASK	GENMASK(31, 0)
 
 /* assigned by firmware, the real filter number for each pf may be less */
 #define MAX_FD_FILTER_NUM	4096
@@ -687,6 +688,7 @@ struct hclge_fd_rule_tuples {
 	u32 l4_user_def;
 	u8 ip_tos;
 	u8 ip_proto;
+	u32 outer_tun_vni;
 };
 
 struct hclge_fd_rule {
-- 
2.33.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API
  2022-08-17 14:35 [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API Guangbin Huang
  2022-08-17 14:35 ` [PATCH net-next 1/2] net: ethtool: " Guangbin Huang
  2022-08-17 14:35 ` [PATCH net-next 2/2] net: hns3: support set/get VxLAN rule of rx flow director by ethtool Guangbin Huang
@ 2022-08-17 18:16 ` Jakub Kicinski
  2022-08-22 14:46   ` huangguangbin (A)
  2 siblings, 1 reply; 8+ messages in thread
From: Jakub Kicinski @ 2022-08-17 18:16 UTC (permalink / raw)
  To: Guangbin Huang
  Cc: davem, idosch, linux, mkubecek, netdev, linux-kernel, lipeng321,
	shenjian15

On Wed, 17 Aug 2022 22:35:36 +0800 Guangbin Huang wrote:
> This series adds support for steering VxLAN flows using the ethtool NFC
> interface, and implements it for hns3 devices.

Why can't TC be used for this? Let's not duplicate the same
functionality in two places, TC flower can already match on 
tunnel headers.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API
  2022-08-17 18:16 ` [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API Jakub Kicinski
@ 2022-08-22 14:46   ` huangguangbin (A)
  2022-08-22 15:48     ` Samudrala, Sridhar
  2022-08-22 16:53     ` Jakub Kicinski
  0 siblings, 2 replies; 8+ messages in thread
From: huangguangbin (A) @ 2022-08-22 14:46 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: davem, idosch, linux, mkubecek, netdev, linux-kernel, lipeng321,
	shenjian15



On 2022/8/18 2:16, Jakub Kicinski wrote:
> On Wed, 17 Aug 2022 22:35:36 +0800 Guangbin Huang wrote:
>> This series adds support for steering VxLAN flows using the ethtool NFC
>> interface, and implements it for hns3 devices.
> 
> Why can't TC be used for this? Let's not duplicate the same
> functionality in two places, TC flower can already match on
> tunnel headers.
> .
> 
Hi Jakub,
1. I check the manual and implement of TC flower, it doesn't seems
    to support configuring flows steering to a specific queue.
2. Our hns3 driver has supported configuring some type of flows
    steering to a specific queue by ethtool -U command, many users
    have already use ethtool way.
3. In addition, if our driver supports TC flower to configure flows
    steering to a specific queue, can we allow user to simultaneously
    use TC flower and ethtool to configure flow rules? Could the rules
    configured by TC flower be queried by ethtool -u?
    If two ways can be existing, I think it is more complicated for
    driver to manage flow rules.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API
  2022-08-22 14:46   ` huangguangbin (A)
@ 2022-08-22 15:48     ` Samudrala, Sridhar
  2022-08-22 16:53     ` Jakub Kicinski
  1 sibling, 0 replies; 8+ messages in thread
From: Samudrala, Sridhar @ 2022-08-22 15:48 UTC (permalink / raw)
  To: huangguangbin (A), Jakub Kicinski
  Cc: davem, idosch, linux, mkubecek, netdev, linux-kernel, lipeng321,
	shenjian15, Nambiar, Amritha

On 8/22/2022 9:46 AM, huangguangbin (A) wrote:
>
>
> On 2022/8/18 2:16, Jakub Kicinski wrote:
>> On Wed, 17 Aug 2022 22:35:36 +0800 Guangbin Huang wrote:
>>> This series adds support for steering VxLAN flows using the ethtool NFC
>>> interface, and implements it for hns3 devices.
>>
>> Why can't TC be used for this? Let's not duplicate the same
>> functionality in two places, TC flower can already match on
>> tunnel headers.
>> .
>>
> Hi Jakub,
> 1. I check the manual and implement of TC flower, it doesn't seems
>    to support configuring flows steering to a specific queue.

Based on the discussion in this email thread
   https://lore.kernel.org/netdev/20220429171717.5b0b2a81@kernel.org/
Amritha will be submitting a patch series soon to enable redirecting to 
a RX qeueue
via  tc flower using skbedit queue_mapping action offload.

- Sridhar

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API
  2022-08-22 14:46   ` huangguangbin (A)
  2022-08-22 15:48     ` Samudrala, Sridhar
@ 2022-08-22 16:53     ` Jakub Kicinski
  2022-08-23  8:20       ` huangguangbin (A)
  1 sibling, 1 reply; 8+ messages in thread
From: Jakub Kicinski @ 2022-08-22 16:53 UTC (permalink / raw)
  To: huangguangbin (A)
  Cc: davem, idosch, linux, mkubecek, netdev, linux-kernel, lipeng321,
	shenjian15

On Mon, 22 Aug 2022 22:46:14 +0800 huangguangbin (A) wrote:
> 1. I check the manual and implement of TC flower, it doesn't seems
>     to support configuring flows steering to a specific queue.

We got an answer from Sridhar on that one (thanks!)
I know it was discussed so it's a SMOC.

> 2. Our hns3 driver has supported configuring some type of flows
>     steering to a specific queue by ethtool -U command, many users
>     have already use ethtool way.
> 3. In addition, if our driver supports TC flower to configure flows
>     steering to a specific queue, can we allow user to simultaneously
>     use TC flower and ethtool to configure flow rules? Could the rules
>     configured by TC flower be queried by ethtool -u?
>     If two ways can be existing, I think it is more complicated for
>     driver to manage flow rules.

I understand your motivation and these are very valid points.
However, we have to draw the line somewhere. We have at least
three ways of configuring flow offloads (ethtool, nft, tc).
Supporting all of them is a lot of work for the drivers, leading
to a situation where there's no "standard Linux API" because each
vendor picks a slightly different approach :(
TC seems the most popular because of the OVS offload, so my preference
is to pick it over the other APIs.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API
  2022-08-22 16:53     ` Jakub Kicinski
@ 2022-08-23  8:20       ` huangguangbin (A)
  0 siblings, 0 replies; 8+ messages in thread
From: huangguangbin (A) @ 2022-08-23  8:20 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: davem, idosch, linux, mkubecek, netdev, linux-kernel, lipeng321,
	shenjian15



On 2022/8/23 0:53, Jakub Kicinski wrote:
> On Mon, 22 Aug 2022 22:46:14 +0800 huangguangbin (A) wrote:
>> 1. I check the manual and implement of TC flower, it doesn't seems
>>      to support configuring flows steering to a specific queue.
> 
> We got an answer from Sridhar on that one (thanks!)
> I know it was discussed so it's a SMOC.
> 
>> 2. Our hns3 driver has supported configuring some type of flows
>>      steering to a specific queue by ethtool -U command, many users
>>      have already use ethtool way.
>> 3. In addition, if our driver supports TC flower to configure flows
>>      steering to a specific queue, can we allow user to simultaneously
>>      use TC flower and ethtool to configure flow rules? Could the rules
>>      configured by TC flower be queried by ethtool -u?
>>      If two ways can be existing, I think it is more complicated for
>>      driver to manage flow rules.
> 
> I understand your motivation and these are very valid points.
> However, we have to draw the line somewhere. We have at least
> three ways of configuring flow offloads (ethtool, nft, tc).
> Supporting all of them is a lot of work for the drivers, leading
> to a situation where there's no "standard Linux API" because each
> vendor picks a slightly different approach :(
> TC seems the most popular because of the OVS offload, so my preference
> is to pick it over the other APIs.
> .
> 
Ok.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-08-23  8:47 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-17 14:35 [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API Guangbin Huang
2022-08-17 14:35 ` [PATCH net-next 1/2] net: ethtool: " Guangbin Huang
2022-08-17 14:35 ` [PATCH net-next 2/2] net: hns3: support set/get VxLAN rule of rx flow director by ethtool Guangbin Huang
2022-08-17 18:16 ` [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API Jakub Kicinski
2022-08-22 14:46   ` huangguangbin (A)
2022-08-22 15:48     ` Samudrala, Sridhar
2022-08-22 16:53     ` Jakub Kicinski
2022-08-23  8:20       ` huangguangbin (A)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).