[dpdk-dev] [PATCH 4/6] ethdev: introduce TX common tunnel offloads

Olivier Matz olivier.matz at 6wind.com
Tue Jan 16 18:10:10 CET 2018


Hi Xueming,

On Tue, Jan 09, 2018 at 10:11:08PM +0800, Xueming Li wrote:
> This patch introduce new DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO flag for
> devices that support tunnel agnostic TX checksum and tso offloading.
> 
> Checksum offset and TSO header length are calculated based on mbuf
> inner length l*_len, outer_l*_len and tx offload flags PKT_TX_*, tunnel
> header length is part of inner l2_len, so device HW do cheksum and TSO
> calculation w/o knowledge of perticular tunnel type.
> 
> When set application must guarantee that correct header types and
> lengths for each inner and outer headers in mbuf header, no need to
> specify tunnel type.
> 
> Signed-off-by: Xueming Li <xuemingl at mellanox.com>
> ---
>  lib/librte_ether/rte_ethdev.h | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index 57b61ed41..8457d01be 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -1003,6 +1003,15 @@ struct rte_eth_conf {
>   *   the same mempool and has refcnt = 1.
>   */
>  #define DEV_TX_OFFLOAD_SECURITY         0x00020000
> +/**< Device supports arbitrary tunnel chksum and tso offloading w/o knowing
> + *   tunnel detail. Checksum and TSO are calculated based on mbuf fields:
> + *     l*_len, outer_l*_len
> + *     PKT_TX_OUTER_IPV6, PKT_TX_IPV6
> + *     PKT_TX_IP_CKSUM, PKT_TX_TCP_CKSUM, PKT_TX_UDP_CKSUM
> + *   When set application must guarantee correct header fields, no need to
> + *   specify tunnel type PKT_TX_TUNNEL_* for HW.
> + */
> +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO	0x00040000
>  
>  struct rte_pci_device;
>  

I'd like to have more details about this flag and its meaning.

Let's say we want to do TSO on the following vxlan packet:
  Ether / IP1 / UDP / VXLAN / Ether / IP2 / TCP / Data

With the current API, we need to pass the tunnel type to the hardware
with the flag PKT_TX_TUNNEL_VXLAN. Thanks to that, the driver can
forward this information to the hardware so it knows that the
ip1->length, udp->length and optionally the udp->chksum have to be
updated for each generated segment.

With your proposal, if I understand properly, it is not expected to pass
the tunnel type in the mbuf. So how can the hardware know if some fields
have to be updated in the outer header?


More information about the dev mailing list