* [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).