[dpdk-dev] [PATCH v3 1/7] ethdev: introduce Tx generic tunnel L3/L4 offload

Yongseok Koh yskoh at mellanox.com
Wed Mar 21 02:40:48 CET 2018


On Mon, Mar 05, 2018 at 10:51:15PM +0800, Xueming Li wrote:
> This patch introduce new TX offload flags for device that supports
> tunnel agnostic L3/L4 checksum and TSO offload.
> 
> The support from the device is for inner and outer checksums on
> IPV4/TCP/UDP and TSO for *any packet with the following format*:
> 
> < some headers > / [optional IPv4/IPv6] / [optional TCP/UDP] / <some
> headers> / [optional inner IPv4/IPv6] / [optional TCP/UDP]
> 
> For example the following packets can use this feature:
> 
> 1. eth / ipv4 / udp / VXLAN / ip / tcp
> 2. eth / ipv4 / GRE / MPLS / ipv4 / udp
> 
> Signed-off-by: Xueming Li <xuemingl at mellanox.com>
> ---
>  lib/librte_ether/rte_ethdev.h | 24 ++++++++++++++++++++++++
>  lib/librte_mbuf/rte_mbuf.c    |  5 +++++
>  lib/librte_mbuf/rte_mbuf.h    | 18 ++++++++++++++++--
>  3 files changed, 45 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index 036153306..66d12d3e0 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -980,6 +980,30 @@ struct rte_eth_conf {
>   *   the same mempool and has refcnt = 1.
>   */
>  #define DEV_TX_OFFLOAD_SECURITY         0x00020000
> +/**< Generic tunnel L3/L4 checksum offload. To enable this offload feature
> + * for a packet to be transmitted on hardware supporting generic tunnel L3/L4
> + * checksum offload:
> + *  - fill outer_l2_len and outer_l3_len in mbuf
> + *  - fill l2_len and l3_len in mbuf
> + *  - set the flags PKT_TX_TUNNEL_xxx (use PKT_TX_TUNNEL_UNKNOWN if undefined)
> + *  - set the flags PKT_TX_OUTER_IP_CKSUM
> + *  - set the flags PKT_TX_IP_CKSUM
> + *  - set the flags PKT_TX_TCP_CKSUM, PKT_TX_SCTP_CKSUM or PKT_TX_UDP_CKSUM
> + */
> +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM	0x00040000

It looks redundant to me. Isn't it same as having DEV_TX_OFFLOAD_*_CKSUM?
According to the API document, when PKT_TX_*_CKSUM is set, all the necessary
length fields should be filled in (e.g. mbuf->outer_l?_len and mbuf->l?_len). It
doesn't need to specify any tunnel type for checksum. For example, in order to
request checksum offload for an unknown tunnel type which is similar to VxLAN,
what should app do? Even without defining this new offload flag, it is currently
possible by setting
	(PKT_TX_OUTER_IP_CKSUM | PKT_TX_OUTER_IPV4 | PKT_TX_IP_CKSUM |
	 PKT_TX_IPV4 | PKT_TX_UDP_CKSUM)
along with various length fields.

> +/**< Generic tunnel segmentation offload. To enable it, the user needs to:
> + *  - fill outer_l2_len and outer_l3_len in mbuf
> + *  - fill l2_len and l3_len in mbuf
> + *  - set the flags PKT_TX_TUNNEL_xxx (use PKT_TX_TUNNEL_UNKNOWN if undefined)
> + *  - set the flags PKT_TX_OUTER_IPV4 or PKT_TX_OUTER_IPV6
> + *  - if it's UDP tunnel, set the flags PKT_TX_OUTER_UDP
> + *  - set the flags PKT_TX_IPV4 or PKT_TX_IPV6
> + *  - set the PKT_TX_TCP_SEG flag in mbuf->ol_flags (this flag implies
> + *    PKT_TX_OUTER_IP_CKSUM, PKT_TX_IP_CKSUM and PKT_TX_TCP_CKSUM)
> + * Hardware that supports generic tunnel TSO offload only update outer/inner
> + * L3/L4 fields, tunnel fields are not touched.
> + */
> +#define DEV_TX_OFFLOAD_GENERIC_TNL_TSO		0x00080000

Practically, for the existing TSO offloads for tunneled packets, tunnel type
(PKT_TX_TUNNEL_*) is needed for knowing if transport is UDP-based or IP-based
because the length field of UDP header should be updated for TSO. AFAIK, there's
no TCP-based tunnel. For PKT_TX_TUNNEL_UNKNOWN, the only thing _unknown_ seems
to be the type of transport and by defining PKT_TX_OUTER_UDP, you seem to
recognize the type of transport between UDP and IP (it's not non-UDP). Given
that, the new flags still look redundant and ambiguous. If PKT_TX_TUNNEL_VXLAN
is set, there's no need to set PKT_TX_OUTER_UDP redundantly.

Instead, I think defining PKT_TX_TUNNEL_UDP_UNKNOWN and PKT_TX_TUNNEL_IP_UNKNOWN
could be a good alternative. It is only my humble two cents and I'd like to hear
from more people regarding this.


Thanks,
Yongseok


More information about the dev mailing list