[8/8] net: mark all big endian types
Checks
Commit Message
Some protocols (ARP, MPLS and HIGIG2) were using uint16_t and uint32_t
types for their 16 and 32-bit fields.
It was correct but not conveying the big endian nature of these fields.
As for other protocols defined in this directory,
all types are explicitly marked as big endian fields.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
lib/net/rte_arp.h | 28 ++++++++++++++--------------
lib/net/rte_higig.h | 6 +++---
lib/net/rte_mpls.h | 2 +-
3 files changed, 18 insertions(+), 18 deletions(-)
Comments
On Tue, Oct 25, 2022 at 11:46 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> diff --git a/lib/net/rte_higig.h b/lib/net/rte_higig.h
> index b55fb1a7db..bba3898a88 100644
> --- a/lib/net/rte_higig.h
> +++ b/lib/net/rte_higig.h
> @@ -112,9 +112,9 @@ struct rte_higig2_ppt_type0 {
> */
> __extension__
> struct rte_higig2_ppt_type1 {
> - uint16_t classification;
> - uint16_t resv;
> - uint16_t vid;
> + rte_be16_t classification;
> + rte_be16_t resv;
> + rte_be16_t vid;
Compiling with sparse (from OVS dpdk-latest), there are, at least,
some annotations missing in the public headers for higig2.
lib/ethdev/rte_flow.h:644: .classification = 0xffff,
lib/ethdev/rte_flow.h:645: .vid = 0xfff,
And the 0xfff mask for a 16 bits field (vid) is suspicious, isn't it?
> #if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> uint16_t opcode:3;
> uint16_t resv1:2;
@@ -23,28 +23,28 @@ extern "C" {
*/
struct rte_arp_ipv4 {
struct rte_ether_addr arp_sha; /**< sender hardware address */
- uint32_t arp_sip; /**< sender IP address */
+ rte_be32_t arp_sip; /**< sender IP address */
struct rte_ether_addr arp_tha; /**< target hardware address */
- uint32_t arp_tip; /**< target IP address */
+ rte_be32_t arp_tip; /**< target IP address */
} __rte_packed __rte_aligned(2);
/**
* ARP header.
*/
struct rte_arp_hdr {
- uint16_t arp_hardware; /* format of hardware address */
-#define RTE_ARP_HRD_ETHER 1 /* ARP Ethernet address format */
+ rte_be16_t arp_hardware; /** format of hardware address */
+#define RTE_ARP_HRD_ETHER 1 /** ARP Ethernet address format */
- uint16_t arp_protocol; /* format of protocol address */
- uint8_t arp_hlen; /* length of hardware address */
- uint8_t arp_plen; /* length of protocol address */
- uint16_t arp_opcode; /* ARP opcode (command) */
-#define RTE_ARP_OP_REQUEST 1 /* request to resolve address */
-#define RTE_ARP_OP_REPLY 2 /* response to previous request */
-#define RTE_ARP_OP_REVREQUEST 3 /* request proto addr given hardware */
-#define RTE_ARP_OP_REVREPLY 4 /* response giving protocol address */
-#define RTE_ARP_OP_INVREQUEST 8 /* request to identify peer */
-#define RTE_ARP_OP_INVREPLY 9 /* response identifying peer */
+ rte_be16_t arp_protocol; /** format of protocol address */
+ uint8_t arp_hlen; /** length of hardware address */
+ uint8_t arp_plen; /** length of protocol address */
+ rte_be16_t arp_opcode; /** ARP opcode (command) */
+#define RTE_ARP_OP_REQUEST 1 /** request to resolve address */
+#define RTE_ARP_OP_REPLY 2 /** response to previous request */
+#define RTE_ARP_OP_REVREQUEST 3 /** request proto addr given hardware */
+#define RTE_ARP_OP_REVREPLY 4 /** response giving protocol address */
+#define RTE_ARP_OP_INVREQUEST 8 /** request to identify peer */
+#define RTE_ARP_OP_INVREPLY 9 /** response identifying peer */
struct rte_arp_ipv4 arp_data;
} __rte_packed __rte_aligned(2);
@@ -112,9 +112,9 @@ struct rte_higig2_ppt_type0 {
*/
__extension__
struct rte_higig2_ppt_type1 {
- uint16_t classification;
- uint16_t resv;
- uint16_t vid;
+ rte_be16_t classification;
+ rte_be16_t resv;
+ rte_be16_t vid;
#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
uint16_t opcode:3;
uint16_t resv1:2;
@@ -23,7 +23,7 @@ extern "C" {
*/
__extension__
struct rte_mpls_hdr {
- uint16_t tag_msb; /**< Label(msb). */
+ rte_be16_t tag_msb; /**< Label(msb). */
#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
uint8_t tag_lsb:4; /**< Label(lsb). */
uint8_t tc:3; /**< Traffic class. */