From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id B941F430CE;
	Tue, 22 Aug 2023 10:55:46 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id EB4AA42B8B;
	Tue, 22 Aug 2023 10:55:45 +0200 (CEST)
Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com
 [209.85.128.50]) by mails.dpdk.org (Postfix) with ESMTP id 14FCE4021D
 for <dev@dpdk.org>; Tue, 22 Aug 2023 10:55:45 +0200 (CEST)
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-3fef56f7223so10858625e9.3
 for <dev@dpdk.org>; Tue, 22 Aug 2023 01:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=6wind.com; s=google; t=1692694544; x=1693299344;
 h=in-reply-to:content-disposition:mime-version:references:message-id
 :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
 bh=b5pC6sI3powce6GeB30e40QrSSGrdQ/h1iOKYStB1jU=;
 b=NB8q9Lw3YuR7V/9XJV7oHsWCdtI/Ibc6VXyho860Gf/dMA+Mt8rh1S0EDf9i72uihm
 1VPWvevGu2XOgfuFH2r2iuQAi4hwd/BzvKmxDKWOKWcOZJaKILi16v9HqWAcsRytMw4D
 N0GfLQzVwmFLiSImUFbzcqJBF/hXguZRXOiGZDsrTWFE/xFZgU/cNaGAIuDU4pPmKHBo
 6ic7v7d1MFSnKqnN94vo1CfMltjtkOo9lbLYsKgG6GpIACX88Itc1rj0bAL69S3N0dE6
 bUJxuHJXQir1d0HjUmwUAnGxHfhpbuFWrJgYTqCPNyEb6X2I+U2u5GwKVUV7ui7HuYzC
 4Nvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1692694544; x=1693299344;
 h=in-reply-to:content-disposition:mime-version:references:message-id
 :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=b5pC6sI3powce6GeB30e40QrSSGrdQ/h1iOKYStB1jU=;
 b=kCcpq0pXdn0cKlvZW8s3bUkqZAK/1EqdqQqdu4BxGecdzDC6fmgmYa7VyaEzvxsAbd
 B7aehrwrGzT9dtn5exvDDrt4s0zrIXc8noWjoDtVf56QFkUtyR1cj4YjrNwi4FIEbZJ2
 S4r5QPb6CWT3k2YOTtP5aKc4sx5a6WBhEX5QBAz4I5ZyiQZ/a4DKlWPrS3W8az6ukZNC
 XLjfsM50WEre10tYQUvpOdSy55nnVfoYVNcyhNC1dSC693B4hWhxp82xNHUFxuDwdHCF
 77x4kiKGGDgZ21Ql/g9ofAI7649RdKFnu3XUEDV2EMuNB24fi0jomqYT1WLtDrndnYP9
 P3Nw==
X-Gm-Message-State: AOJu0Yx1T7b7n5EzUx4tUDIFGv3yvMUglevn3ObeyJDehUe9J/FJE7pc
 z94qwDjp0TgSbB9lBcHInzdV/w==
X-Google-Smtp-Source: AGHT+IHpsqXMDCUZ6/trXsYO7JS3y5/0xH13RQvS0ZAn7snbw1zZ/G6yp2wM43XMuAIC3Fxd6OHq8g==
X-Received: by 2002:a5d:49cf:0:b0:313:f957:bf29 with SMTP id
 t15-20020a5d49cf000000b00313f957bf29mr6240718wrs.65.1692694544686; 
 Tue, 22 Aug 2023 01:55:44 -0700 (PDT)
Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25])
 by smtp.gmail.com with ESMTPSA id
 q16-20020a05600000d000b0031c56218984sm5276295wrx.104.2023.08.22.01.55.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 22 Aug 2023 01:55:44 -0700 (PDT)
Date: Tue, 22 Aug 2023 10:55:43 +0200
From: Olivier Matz <olivier.matz@6wind.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, stable@dpdk.org, Ales Musil <amusil@redhat.com>,
 Thomas Monjalon <thomas@monjalon.net>, Ophir Munk <ophirmu@nvidia.com>,
 Keith Wiles <keith.wiles@intel.com>,
 Raslan Darawsheh <rasland@mellanox.com>
Subject: Re: [PATCH] net/tap: fix L4 checksum
Message-ID: <ZOR4DzpdH4KftTWT@platinum>
References: <20230822073244.3751885-1-david.marchand@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230822073244.3751885-1-david.marchand@redhat.com>
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

Hi David,

On Tue, Aug 22, 2023 at 09:32:44AM +0200, David Marchand wrote:
> The L4 checksum offloading API does not require l4_len to be set.
> Make the driver discover the L4 headers size by itself.
> 
> Fixes: 6546e76056e3 ("net/tap: calculate checksums of multi segs packets")
> Cc: stable@dpdk.org
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> Tested-by: Ales Musil <amusil@redhat.com>
> ---
>  .mailmap                      |  1 +
>  drivers/net/tap/rte_eth_tap.c | 13 +++++++++++--
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/.mailmap b/.mailmap
> index 864d33ee46..b6a21b35cb 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -40,6 +40,7 @@ Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>  Aleksandr Miloshenko <a.miloshenko@f5.com>
>  Aleksey Baulin <aleksey.baulin@gmail.com>
>  Aleksey Katargin <gureedo@gmail.com>
> +Ales Musil <amusil@redhat.com>
>  Alexander Bechikov <asb.tyum@gmail.com>
>  Alexander Belyakov <abelyako@gmail.com>
>  Alexander Chernavin <achernavin@netgate.com>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index bf98f75559..0ab214847a 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -645,13 +645,22 @@ tap_write_mbufs(struct tx_queue *txq, uint16_t num_mbufs,
>  		    ((mbuf->ol_flags & (RTE_MBUF_F_TX_IP_CKSUM | RTE_MBUF_F_TX_IPV4) ||
>  		      (mbuf->ol_flags & RTE_MBUF_F_TX_L4_MASK) == RTE_MBUF_F_TX_UDP_CKSUM ||
>  		      (mbuf->ol_flags & RTE_MBUF_F_TX_L4_MASK) == RTE_MBUF_F_TX_TCP_CKSUM))) {

While looking at the patch, I noticed this line:

  mbuf->ol_flags & (RTE_MBUF_F_TX_IP_CKSUM | RTE_MBUF_F_TX_IPV4)

I think only RTE_MBUF_F_TX_IP_CKSUM should be checked.

> +			unsigned int l4_len = 0;
> +
>  			is_cksum = 1;
>  
> +			if ((mbuf->ol_flags & RTE_MBUF_F_TX_L4_MASK) ==
> +					RTE_MBUF_F_TX_UDP_CKSUM)
> +				l4_len = sizeof(struct rte_udp_hdr);
> +			else if ((mbuf->ol_flags & RTE_MBUF_F_TX_L4_MASK) ==
> +					RTE_MBUF_F_TX_TCP_CKSUM)
> +				l4_len = sizeof(struct rte_tcp_hdr);
> +
>  			/* Support only packets with at least layer 4
>  			 * header included in the first segment
>  			 */
>  			seg_len = rte_pktmbuf_data_len(mbuf);
> -			l234_hlen = mbuf->l2_len + mbuf->l3_len + mbuf->l4_len;
> +			l234_hlen = mbuf->l2_len + mbuf->l3_len + l4_len;
>  			if (seg_len < l234_hlen)
>  				return -1;
>  
> @@ -661,7 +670,7 @@ tap_write_mbufs(struct tx_queue *txq, uint16_t num_mbufs,
>  			rte_memcpy(m_copy, rte_pktmbuf_mtod(mbuf, void *),
>  					l234_hlen);
>  			tap_tx_l3_cksum(m_copy, mbuf->ol_flags,
> -				       mbuf->l2_len, mbuf->l3_len, mbuf->l4_len,
> +				       mbuf->l2_len, mbuf->l3_len, l4_len,
>  				       &l4_cksum, &l4_phdr_cksum,
>  				       &l4_raw_cksum);
>  			iovecs[k].iov_base = m_copy;
> -- 
> 2.41.0
> 

Using rte_ipv4_udptcp_cksum() in this code would probably simplify it, and may
solve other issues (for instance the 0 checksum for UDP which has a special
meaning).