From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 930C5A0547
for <public@inbox.dpdk.org>; Fri, 30 Apr 2021 16:48:52 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 840B940A4B;
Fri, 30 Apr 2021 16:48:52 +0200 (CEST)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
by mails.dpdk.org (Postfix) with ESMTP id A50934013F;
Fri, 30 Apr 2021 16:48:49 +0200 (CEST)
IronPort-SDR: F43oP8VnkrGbsCqt3SCccbEoEACVA9iTX2+CY7xJJyYSf8faUqbbjbgcDvsZ3plX+z1zGuo8Vb
XWdqEvySINNA==
X-IronPort-AV: E=McAfee;i="6200,9189,9970"; a="197387014"
X-IronPort-AV: E=Sophos;i="5.82,262,1613462400"; d="scan'208";a="197387014"
Received: from fmsmga008.fm.intel.com ([10.253.24.58])
by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
30 Apr 2021 07:48:47 -0700
IronPort-SDR: 7fgc8Xr60zxboDVOeyvdHr5mW+XyUjrMqD5Na8qj95NzTr0idCiNjN1xphJtBrHs7915YiRue/
ARGDpJxu9KGQ==
X-IronPort-AV: E=Sophos;i="5.82,262,1613462400"; d="scan'208";a="425039634"
Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.242.68])
([10.213.242.68])
by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
30 Apr 2021 07:48:45 -0700
To: Olivier Matz <olivier.matz@6wind.com>, dev@dpdk.org
Cc: Keith Wiles <keith.wiles@intel.com>, Hongzhi Guo
<guohongzhi1@huawei.com>, =?UTF-8?Q?Morten_Br=c3=b8rup?=
<mb@smartsharesystems.com>, Thomas Monjalon <thomas@monjalon.net>,
stable@dpdk.org
References: <20210427135755.927-1-olivier.matz@6wind.com>
<20210427135755.927-2-olivier.matz@6wind.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
X-User: ferruhy
Message-ID: <5fa9bc52-0862-983e-3e38-33a937872571@intel.com>
Date: Fri, 30 Apr 2021 15:48:43 +0100
MIME-Version: 1.0
In-Reply-To: <20210427135755.927-2-olivier.matz@6wind.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-stable] [PATCH 1/4] net/tap: fix Rx cksum flags on IP
options packets
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
On 4/27/2021 2:57 PM, Olivier Matz wrote:
> When packet type is IPV4_EXT, the checksum is always marked as good in
> the mbuf offload flags.
>
> Since we know the header lengths, we can easily call
> rte_ipv4_udptcp_cksum() in this case too.
>
> Fixes: 8ae3023387e9 ("net/tap: add Rx/Tx checksum offload support")
> Cc: stable@dpdk.org
>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> ---
> drivers/net/tap/rte_eth_tap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index 68baa18523..e7b185a4b5 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -350,7 +350,7 @@ tap_verify_csum(struct rte_mbuf *mbuf)
> /* Don't verify checksum for multi-segment packets. */
> if (mbuf->nb_segs > 1)
> return;
> - if (l3 == RTE_PTYPE_L3_IPV4) {
> + if (l3 == RTE_PTYPE_L3_IPV4 || l3 == RTE_PTYPE_L3_IPV4_EXT) {
Should we take 'RTE_PTYPE_L3_IPV4_EXT_UNKNOWN' into account?
> if (l4 == RTE_PTYPE_L4_UDP) {
> udp_hdr = (struct rte_udp_hdr *)l4_hdr;
> if (udp_hdr->dgram_cksum == 0) {
> @@ -364,7 +364,7 @@ tap_verify_csum(struct rte_mbuf *mbuf)
> }
> }
> cksum = ~rte_ipv4_udptcp_cksum(l3_hdr, l4_hdr);
> - } else if (l3 == RTE_PTYPE_L3_IPV6) {
> + } else { /* l3 == RTE_PTYPE_L3_IPV6, checked above */
> cksum = ~rte_ipv6_udptcp_cksum(l3_hdr, l4_hdr);
> }
> mbuf->ol_flags |= cksum ?
>