From patchwork Fri Apr 5 14:45:57 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Marchand X-Patchwork-Id: 139129 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 28A5B43E06; Fri, 5 Apr 2024 16:46:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 76754406A2; Fri, 5 Apr 2024 16:46:37 +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 DEFD040697 for ; Fri, 5 Apr 2024 16:46:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712328396; 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=REBFzQAC7/NjyH/rT1TMQpAfP+l63csuL+ixPiIZbAlo0xouSn/25OOGeq1lsjHDFMy2Uc sV9DWeWyijLcsDQL61PFcc+oITuSWvs6vpLj2JMBgXsDTarSescRt1bcz5PirA6BtO/wUz bN12QEVX5dPMscIDoczx3H8IK8xB5s4= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-651-Gk_Q3cP2OAWirFfVRfotRA-1; Fri, 05 Apr 2024 10:46:32 -0400 X-MC-Unique: Gk_Q3cP2OAWirFfVRfotRA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 B755238000AE; Fri, 5 Apr 2024 14:46:31 +0000 (UTC) Received: from dmarchan.redhat.com (unknown [10.45.225.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id 75EECC04221; Fri, 5 Apr 2024 14:46:30 +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 v2 3/8] mbuf: fix Tx checksum offload examples Date: Fri, 5 Apr 2024 16:45:57 +0200 Message-ID: <20240405144604.906695-4-david.marchand@redhat.com> In-Reply-To: <20240405144604.906695-1-david.marchand@redhat.com> References: <20240405125039.897933-1-david.marchand@redhat.com> <20240405144604.906695-1-david.marchand@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 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