From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C1E45A034F; Tue, 8 Jun 2021 12:14:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 458B04067A; Tue, 8 Jun 2021 12:14:02 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 50CF84013F; Tue, 8 Jun 2021 12:14:00 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id D93A27F664; Tue, 8 Jun 2021 13:13:59 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru D93A27F664 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1623147239; bh=BXLNq0YBsE0tkqtr20WytPxUQv3IUpK2BfV3ikIxbIQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=TPXvFM3mZHb5+w4eIAYt/nSK5oWGvJpanoXE0SWyCpB7vL6slOOe+QmqWua0gmwg6 JXIOOO/f2SnZfyn6d5V/AAoynb9egQdTXSpUy5+rBub9BAaDUUglP24gQoLV8KAO6x 0MNRpmL/YSPcdd72rXLIdCK4UjamhFN2oq/rGaYU= To: Ferruh Yigit , Olivier Matz , dev@dpdk.org Cc: Keith Wiles , Hongzhi Guo , =?UTF-8?Q?Morten_Br=c3=b8rup?= , Thomas Monjalon , stable@dpdk.org References: <20210427135755.927-1-olivier.matz@6wind.com> <20210427135755.927-2-olivier.matz@6wind.com> <5fa9bc52-0862-983e-3e38-33a937872571@intel.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <39a8a8bb-d246-3377-607c-3c2387b73fe0@oktetlabs.ru> Date: Tue, 8 Jun 2021 13:13:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <5fa9bc52-0862-983e-3e38-33a937872571@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 1/4] net/tap: fix Rx cksum flags on IP options packets 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 Sender: "dev" On 4/30/21 5:48 PM, Ferruh Yigit wrote: > 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 >> --- >> 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? I think we should. > >> 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 ? >>