Skip to contentSkip to conversation

Add support for RX packet classification in a network device

PATCH In review [email protected] 3 participants 6 messages Feb 9, 2009 – Feb 10, 2009

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

[email protected]

author
#0 lore raw

PATCH 1/3 Add support for RX packet classification in a network device

From: Santwona Behera <[email protected]> [PATCH 1/3] [ethtool] Add RX pkt classification interface

Signed-off-by Santwona Behera <[email protected]>
---
 ethtool-copy.h |   82 ++++-
 ethtool.8      |  138 +++++++-
 ethtool.c      | 1070 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 1260 insertions(+), 30 deletions(-)
ethtool-copy.h +78 -4
index eadba25..8c61f3e 100644
@@ -12,6 +12,8 @@
 #ifndef _LINUX_ETHTOOL_H
 #define _LINUX_ETHTOOL_H
 
+#include <linux/types.h>
+
 /* This should work for both 32 and 64 bit userland. */
 struct ethtool_cmd {
 	__u32	cmd;

@@ -285,10 +287,71 @@ enum ethtool_flags {
 	ETH_FLAG_LRO		= (1 << 15),	/* LRO is enabled */
 };
 
-struct ethtool_rxnfc {
-	__u32		cmd;
+struct ethtool_tcpip4_spec {
+	__u32	ip4src;
+	__u32	ip4dst;
+	__u16	psrc;
+	__u16	pdst;
+	__u8    tos;
+};
+
+struct ethtool_ah_espip4_spec {
+	__u32	ip4src;
+	__u32	ip4dst;
+	__u32	spi;
+	__u8    tos;
+};
+
+struct ethtool_rawip4_spec {
+	__u32	ip4src;
+	__u32	ip4dst;
+	__u8	hdata[64];
+};
+
+struct ethtool_ether_spec {
+	__u16	ether_type;
+	__u8	frame_size;
+	__u8	eframe[16];
+};
+
+#define	ETH_RX_NFC_IP4	1
+#define	ETH_RX_NFC_IP6	2
+
+struct ethtool_usrip4_spec {
+	__u32	ip4src;
+	__u32	ip4dst;
+	__u32	l4_4_bytes;
+	__u8    tos;
+	__u8    ip_ver;
+	__u8    proto;
+};
+
+struct ethtool_rx_flow_spec {
 	__u32		flow_type;
-	__u64		data;
+	union
+	{
+		struct ethtool_tcpip4_spec		tcp_ip4_spec;
+		struct ethtool_tcpip4_spec		udp_ip4_spec;
+		struct ethtool_tcpip4_spec		sctp_ip4_spec;
+		struct ethtool_ah_espip4_spec		ah_ip4_spec;
+		struct ethtool_ah_espip4_spec		esp_ip4_spec;
+		struct ethtool_rawip4_spec		raw_ip4_spec;
+		struct ethtool_ether_spec		ether_spec;
+		struct ethtool_usrip4_spec		usr_ip4_spec;
+		__u8					hdata[64];
+	} h_u, m_u; /* entry, mask */
+	__u64		ring_cookie;
+	__u32		location;
+};
+
+struct ethtool_rxnfc {
+	__u32				cmd;
+	__u32				flow_type;
+	/* The rx flow hash value or the rule DB size or the # rx rings */
+	__u64				data;
+	struct ethtool_rx_flow_spec	fs;
+	__u32				rule_cnt;
+	__u32				rule_locs[0];
 };
 
 /* CMDs currently supported */

@@ -336,6 +399,12 @@ struct ethtool_rxnfc {
 
 #define	ETHTOOL_GRXFH		0x00000029 /* Get RX flow hash configuration */
 #define	ETHTOOL_SRXFH		0x0000002a /* Set RX flow hash configuration */
+#define	ETHTOOL_GRXRINGS	0x0000002d /* Get RX rings available for LB */
+#define	ETHTOOL_GRXCLSRLCNT	0x0000002e /* Get RX class rule count */
+#define	ETHTOOL_GRXCLSRULE	0x0000002f /* Get RX classification rule */
+#define	ETHTOOL_GRXCLSRLALL	0x00000030 /* Get all RX classification rule */
+#define	ETHTOOL_SRXCLSRLDEL	0x00000031 /* Delete RX classification rule */
+#define	ETHTOOL_SRXCLSRLINS	0x00000032 /* Insert RX classification rule */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSET		ETHTOOL_GSET

@@ -432,9 +501,13 @@ struct ethtool_rxnfc {
 #define	UDP_V6_FLOW	0x06
 #define	SCTP_V6_FLOW	0x07
 #define	AH_ESP_V6_FLOW	0x08
+#define	AH_V4_FLOW	0x09
+#define	ESP_V4_FLOW	0x0a
+#define	AH_V6_FLOW	0x0b
+#define	ESP_V6_FLOW	0x0c
+#define	IP_USER_FLOW	0x0d
 
 /* L3-L4 network traffic flow hash options */
-#define	RXH_DEV_PORT	(1 << 0)
 #define	RXH_L2DA	(1 << 1)
 #define	RXH_VLAN	(1 << 2)
 #define	RXH_L3_PROTO	(1 << 3)

@@ -444,5 +517,6 @@ struct ethtool_rxnfc {
 #define	RXH_L4_B_2_3	(1 << 7) /* dst port in case of TCP/UDP/SCTP */
 #define	RXH_DISCARD	(1 << 31)
 
+#define	RX_CLS_FLOW_DISC	0xffffffffffffffffULL
 
 #endif /* _LINUX_ETHTOOL_H */
ethtool.8 +132 -6

184 lines not on this page · raw message

ethtool.c +1050 -20

1,204 lines not on this page · raw message

Signature · 1 line
1.6.0.4
#1 lore raw

Once the ethtool interface change is accepted in the upstream kernel, I will be happy to add ethtool(8) support.

I would say, though, adding 1000 lines of code, you might as well put that into a new file rxclass.c, to keep all that together in a nice tidy unit.

Jeff

author
#2 lore raw
Quoted 3 lines · Jeff Garzik

Once the ethtool interface change is accepted in the upstream kernel, I will be happy to add ethtool(8) support.

I would say, though, adding 1000 lines of code, you might as well put that into a new file rxclass.c, to keep all that together in a nice tidy unit.

I agree. I will redo the ethtool(8) patch as recommended.

thanks,
--santwona

Quoted 6 lines

Jeff

maintainer
#3 lore raw
In reply to [email protected]

From: [email protected]
Date: Mon, 09 Feb 2009 15:12:21 -0800

ethtool-copy.h enum ethtool_flags { · line 296

Quoted 7 lines
ethtool-copy.h +7 -0
+struct ethtool_tcpip4_spec {
+	__u32	ip4src;
+	__u32	ip4dst;
+	__u16	psrc;
+	__u16	pdst;
+	__u8    tos;
+};

The IP addresses and ports in these new interfaces, are they to be specified in network or cpu byte order?

That's usually the first thing a person will wonder when trying to use to implement support for these interfaces.

My guess is that the specification is cpu endianness, however note that this flies in the face with how this is handled in pretty much every other networking interface in the kernel. The standard is to use network endianness when passing ports and IP addressing information into the kernel.

I wouldn't reject this patch series just for this reason, in fact I'm ready to apply this stuff, but just thought I'd mention it just in case you hadn't considered the issue yourself.

author
#4 lore raw
Quoted 13 lines · David Miller

From: [email protected]
Date: Mon, 09 Feb 2009 15:12:21 -0800

ethtool-copy.h enum ethtool_flags { · line 296

Quoted 7 lines
ethtool-copy.h +7 -0
+struct ethtool_tcpip4_spec {
+	__u32	ip4src;
+	__u32	ip4dst;
+	__u16	psrc;
+	__u16	pdst;
+	__u8    tos;
+};

The IP addresses and ports in these new interfaces, are they to be specified in network or cpu byte order?

The interfaces assumes that they are to be specified in network order. I will add a comment to mention that.

Looking back at my ethtool(8) patch, I have a bug in the code where I do not do this translation for the ports and spi (I got it right for the IP addresses). I will fix this and repost all the patches.

Thanks for raising this.

--santwona

Quoted 15 lines

That's usually the first thing a person will wonder when trying to use to implement support for these interfaces.

My guess is that the specification is cpu endianness, however note that this flies in the face with how this is handled in pretty much every other networking interface in the kernel. The standard is to use network endianness when passing ports and IP addressing information into the kernel.

I wouldn't reject this patch series just for this reason, in fact I'm ready to apply this stuff, but just thought I'd mention it just in case you hadn't considered the issue yourself.

maintainer
#5 lore raw

From: [email protected]
Date: Mon, 09 Feb 2009 19:17:09 -0800

Quoted 6 lines

The interfaces assumes that they are to be specified in network order. I will add a comment to mention that.

Looking back at my ethtool(8) patch, I have a bug in the code where I do not do this translation for the ports and spi (I got it right for the IP addresses). I will fix this and repost all the patches.

Thank you.