From patchwork Fri Apr 5 12:49:42 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Marchand X-Patchwork-Id: 139120 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A004543E01; Fri, 5 Apr 2024 14:51:30 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2CC3B40693; Fri, 5 Apr 2024 14:51:29 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id C04F7402F2 for ; Fri, 5 Apr 2024 14:51:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712321487; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v9Xq8FQK1hfn9g+vFXPNjevKVPrRQdO54XU4Uu1gDH0=; b=WTw9dCnVquXVCGtarF2ho3KJcO0UKhi35caqzfvXFVPsSbqVaedpicP4eDIRXh1mJqFCUq jNj/fcCtsejx1I3wmobC7dwNnNoWlftQdpGDjFLMOqIDGUEPoa1KOh0mLyBAd7dqLeC5C/ BBTgwwGGP/9zet22sXsfeHYGKwjQQSw= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-339-Mab12dowPaa5NXUiJgtLcA-1; Fri, 05 Apr 2024 08:51:26 -0400 X-MC-Unique: Mab12dowPaa5NXUiJgtLcA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8906E8007BB; Fri, 5 Apr 2024 12:51:25 +0000 (UTC) Received: from dmarchan.redhat.com (unknown [10.45.225.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id 470251121313; Fri, 5 Apr 2024 12:51:24 +0000 (UTC) From: David Marchand To: dev@dpdk.org Cc: thomas@monjalon.net, ferruh.yigit@amd.com, stable@dpdk.org, Olivier Matz , Jijiang Liu Subject: [PATCH 3/8] mbuf: fix Tx checksum offload examples Date: Fri, 5 Apr 2024 14:49:42 +0200 Message-ID: <20240405125039.897933-4-david.marchand@redhat.com> In-Reply-To: <20240405125039.897933-1-david.marchand@redhat.com> References: <20240405125039.897933-1-david.marchand@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Mandate use of rte_eth_tx_prepare() in the mbuf Tx checksum offload examples. Remove unneeded resetting of checksums to align with the mbuf API doxygen. Clarify the case when requesting "inner" checksum offload with lack of outer L4 checksum offload. Fixes: f00dcb7b0a74 ("mbuf: fix Tx checksum offload API doc") Fixes: 609dd68ef14f ("mbuf: enhance the API documentation of offload flags") Cc: stable@dpdk.org Signed-off-by: David Marchand --- doc/guides/prog_guide/mbuf_lib.rst | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/doc/guides/prog_guide/mbuf_lib.rst b/doc/guides/prog_guide/mbuf_lib.rst index 049357c755..4e285c0aab 100644 --- a/doc/guides/prog_guide/mbuf_lib.rst +++ b/doc/guides/prog_guide/mbuf_lib.rst @@ -126,6 +126,9 @@ processing to the hardware if it supports it. For instance, the RTE_MBUF_F_TX_IP_CKSUM flag allows to offload the computation of the IPv4 checksum. +Support for such processing by the hardware is advertised through RTE_ETH_TX_OFFLOAD_* capabilities. +Please note that a call to ``rte_eth_tx_prepare`` is needed to handle driver specific requirements such as resetting some checksum fields. + The following examples explain how to configure different TX offloads on a vxlan-encapsulated tcp packet: ``out_eth/out_ip/out_udp/vxlan/in_eth/in_ip/in_tcp/payload`` @@ -135,7 +138,6 @@ a vxlan-encapsulated tcp packet: mb->l2_len = len(out_eth) mb->l3_len = len(out_ip) mb->ol_flags |= RTE_MBUF_F_TX_IPV4 | RTE_MBUF_F_TX_IP_CSUM - set out_ip checksum to 0 in the packet This is supported on hardware advertising RTE_ETH_TX_OFFLOAD_IPV4_CKSUM. @@ -144,8 +146,6 @@ a vxlan-encapsulated tcp packet: mb->l2_len = len(out_eth) mb->l3_len = len(out_ip) mb->ol_flags |= RTE_MBUF_F_TX_IPV4 | RTE_MBUF_F_TX_IP_CSUM | RTE_MBUF_F_TX_UDP_CKSUM - set out_ip checksum to 0 in the packet - set out_udp checksum to pseudo header using rte_ipv4_phdr_cksum() This is supported on hardware advertising RTE_ETH_TX_OFFLOAD_IPV4_CKSUM and RTE_ETH_TX_OFFLOAD_UDP_CKSUM. @@ -155,7 +155,6 @@ a vxlan-encapsulated tcp packet: mb->l2_len = len(out_eth + out_ip + out_udp + vxlan + in_eth) mb->l3_len = len(in_ip) mb->ol_flags |= RTE_MBUF_F_TX_IPV4 | RTE_MBUF_F_TX_IP_CSUM - set in_ip checksum to 0 in the packet This is similar to case 1), but l2_len is different. It is supported on hardware advertising RTE_ETH_TX_OFFLOAD_IPV4_CKSUM. @@ -166,8 +165,6 @@ a vxlan-encapsulated tcp packet: mb->l2_len = len(out_eth + out_ip + out_udp + vxlan + in_eth) mb->l3_len = len(in_ip) mb->ol_flags |= RTE_MBUF_F_TX_IPV4 | RTE_MBUF_F_TX_IP_CSUM | RTE_MBUF_F_TX_TCP_CKSUM - set in_ip checksum to 0 in the packet - set in_tcp checksum to pseudo header using rte_ipv4_phdr_cksum() This is similar to case 2), but l2_len is different. It is supported on hardware advertising RTE_ETH_TX_OFFLOAD_IPV4_CKSUM and @@ -181,9 +178,6 @@ a vxlan-encapsulated tcp packet: mb->l4_len = len(in_tcp) mb->ol_flags |= RTE_MBUF_F_TX_IPV4 | RTE_MBUF_F_TX_IP_CKSUM | RTE_MBUF_F_TX_TCP_CKSUM | RTE_MBUF_F_TX_TCP_SEG; - set in_ip checksum to 0 in the packet - set in_tcp checksum to pseudo header without including the IP - payload length using rte_ipv4_phdr_cksum() This is supported on hardware advertising RTE_ETH_TX_OFFLOAD_TCP_TSO. Note that it can only work if outer L4 checksum is 0. @@ -196,12 +190,10 @@ a vxlan-encapsulated tcp packet: mb->l3_len = len(in_ip) mb->ol_flags |= RTE_MBUF_F_TX_OUTER_IPV4 | RTE_MBUF_F_TX_OUTER_IP_CKSUM | \ RTE_MBUF_F_TX_IP_CKSUM | RTE_MBUF_F_TX_TCP_CKSUM; - set out_ip checksum to 0 in the packet - set in_ip checksum to 0 in the packet - set in_tcp checksum to pseudo header using rte_ipv4_phdr_cksum() This is supported on hardware advertising RTE_ETH_TX_OFFLOAD_IPV4_CKSUM, RTE_ETH_TX_OFFLOAD_UDP_CKSUM and RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM. + Note that it can only work if outer L4 checksum is 0. The list of flags and their precise meaning is described in the mbuf API documentation (rte_mbuf.h). Also refer to the testpmd source code