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
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 <[email protected]>
---
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
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.
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.
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/[email protected]/
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
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.
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.