Hi Ophir,
Please find some comments below.
On Tue, Sep 15, 2020 at 01:17:15PM +0000, Ophir Munk wrote:
> From: Ophir Munk <ophi...@mellanox.com>
>
> GENEVE is a widely used tunneling protocol in modern Virtualized
> Networks. testpmd already supports parsing of several tunneling
> protocols including VXLAN, VXLAN-GPE, GRE. This commit adds GENEVE
> parsing of inner protocols (IPv4-0x0800, IPv6-0x86dd, Ethernet-0x6558)
> based on IETF draft-ietf-nvo3-geneve-09. GENEVE is considered more
> flexible than the other protocols. In terms of protocol format GENEVE
> header has a variable length options as opposed to other tunneling
> protocols which have a fixed header size.
>
> Signed-off-by: Ophir Munk <ophi...@mellanox.com>
> app/test-pmd/csumonly.c | 70 ++++++++++++++++++++++++++++++++++++++++++-
> app/test-pmd/testpmd.h | 1 +
> lib/librte_net/meson.build | 3 +-
> lib/librte_net/rte_geneve.h | 72
> +++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 144 insertions(+), 2 deletions(-)
> create mode 100644 lib/librte_net/rte_geneve.h
An entry could be added in doc/api/doxy-api-index.md. Some more protocols
are missing, I'll send a patch to add them.
> --- /dev/null
> +++ b/lib/librte_net/rte_geneve.h
> @@ -0,0 +1,72 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright 2020 Mellanox Technologies, Ltd
> + */
> +
> +#ifndef _RTE_GENEVE_H_
> +#define _RTE_GENEVE_H_
> +
> +/**
> + * @file
> + *
> + * GENEVE-related definitions
> + */
> +
> +#include <stdint.h>
> +
> +#include <rte_udp.h>
Is this include needed? Maybe it comes from a copy/paste of VXLAN?
> +
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/** GENEVE default port. */
> +#define RTE_GENEVE_DEFAULT_PORT 6081
> +
> +/**
> + * GENEVE protocol header. (draft-ietf-nvo3-geneve-09)
> + * Contains:
> + * 2-bits version (must be 0).
> + * 6-bits option length in four byte multiples, not including the eight
> + * bytes of the fixed tunnel header.
> + * 1-bit control packet.
> + * 1-bit critical options in packet.
> + * 6-bits reserved
> + * 16-bits Protocol Type. The protocol data unit after the Geneve header
> + * following the EtherType convention. Ethernet itself is represented by
> + * the value 0x6558.
> + * 24-bits Virtual Network Identifier (VNI). Virtual network unique
> identified.
> + * 8-bits reserved bits (must be 0 on transmission and ignored on receipt).
> + * More-bits (optional) variable length options.
> + */
> +__extension__
> +struct rte_geneve_hdr {
> +#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
> + uint8_t ver:2; /**< Version (2). */
Isn't the (2) in the comment redundant with the :2 in the type?
Here is how bitfield look like in doxygen documentation:
https://doc.dpdk.org/api/structrte__flow__attr.html#ae4d19341d5298a2bc61f9eb941b1179c
It's true that the field documentation miss the number of bits.
So if you feel it's needed, I prefer something more explicit like "(2 bits)"
instead of just "(2)".
By the way, there are 2 spaces at the end of the comment.
> + uint8_t opt_len:6; /**< Options length (6). */
> + uint8_t oam:1; /**< Control packet (1). */
> + uint8_t critical:1; /**< Critical packet (1). */
> + uint8_t rsvd1:6; /**< Reserved (6). */
"reserved" instead of "rsvd"?
The Internet-Draft says "Rsvd" for this one, but "Reserved" for the other.
> +#else
> + uint8_t opt_len:6; /**< Options length (6). */
> + uint8_t ver:2; /**< Version (2). */
> + uint8_t rsvd1:6; /**< Reserved (6). */
> + uint8_t critical:1; /**< Critical packet (1). */
> + uint8_t oam:1; /**< Control packet (1). */
> +#endif
> + rte_be16_t proto; /**< Protocol type (16). */
> + uint8_t vni[3]; /**< Virtual network identifier (24). */
> + uint8_t rsvd2; /**< Reserved (8). */
vni is an identifier, so I wonder if it would make sense to have
it as an integer instead of an array of uint8. Something like this:
#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
uint32_t vni:24;
uint32_t reserved2:8;
#else
uint32_t vni:24;
uint32_t reserved2:8;
#endif
> + uint8_t opts[]; /**<Variable length options. */
Since the option length is a multiple of four-bytes, would uint32_t[]
make more sense here?
Missing a space after "<".
> +} __rte_packed;
> +
> +/* GENEVE next protocol types */
> +#define RTE_GENEVE_TYPE_IPV4 0x0800 /**< IPv4 Protocol. */
> +#define RTE_GENEVE_TYPE_IPV6 0x86dd /**< IPv6 Protocol. */
> +#define RTE_GENEVE_TYPE_ETH 0x6558 /**< Ethernet Protocol. */
>From what I understand in the draft, I think only RTE_GENEVE_TYPE_ETH
is needed.
Protocol Type (16 bits): The type of the protocol data unit
appearing after the Geneve header. This follows the EtherType
[ETYPES] convention; with Ethernet itself being represented by the
value 0x6558.
Shouldn't we use RTE_ETHER_TYPE_* instead of redefining them here?
0x6558 is RTE_ETHER_TYPE_TEB (Transparent Ethernet Bridging) and is
also used in case of NVGRE.
Regards,
Olivier
