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 5178FA0C40; Tue, 8 Jun 2021 14:34:38 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 16D9B40689; Tue, 8 Jun 2021 14:34:38 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 3CFB84067A; Tue, 8 Jun 2021 14:34:37 +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)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id CE2BE7F514; Tue, 8 Jun 2021 15:34:36 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru CE2BE7F514 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1623155676; bh=bqRe3OUNOD81Ro9dfYN2F4aEcXOu+56mTzI/Hxnd5wM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=b2chdkn0o9s3tQ9MGOQcYAJ9WxY8djBpbFp8Wq236juZrdmkoL7IwfbzkvcZsm6vm oljvGv49qux1GFcjzDW0A7gdmAQkjy68Sn3kn9obYJ8cRC1uM4G6YecZPzXNdnXZ/I g/p+dbQZgd76AreM+XZJRisnDgiG2uBLz5jJh468= To: Olivier Matz Cc: Ferruh Yigit , dev@dpdk.org, 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> <39a8a8bb-d246-3377-607c-3c2387b73fe0@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <359f754b-6ee3-d3e4-5cfc-06f399db9617@oktetlabs.ru> Date: Tue, 8 Jun 2021 15:34:36 +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: 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 6/8/21 3:29 PM, Olivier Matz wrote: > Hi Ferruh, Andrew, > > On Tue, Jun 08, 2021 at 01:13:59PM +0300, Andrew Rybchenko wrote: >> 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. > > I think 'RTE_PTYPE_L3_IPV4_EXT_UNKNOWN' cannot happen here: > > - mbuf->packet_type is generated by (), which cannot > return 'RTE_PTYPE_L3_IPV4_EXT_UNKNOWN' My question if it is guaranteed and the only possible branch. Can application set packet_type itself and do not call rte_net_get_ptype(). Yes, typically application knows if it has IPv4 options in the header or not, but theoretically could be unaware as well. > - right above this code, we already returned if l3 is not in > (RTE_PTYPE_L3_IPV4, RTE_PTYPE_L3_IPV4_EXT, RTE_PTYPE_L3_IPV6) If so, it sounds like it should be allowed above as well. > >>> >>>> 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 ? >>>> >>