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 79089A0C40 for ; Tue, 8 Jun 2021 15:57:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C79D4067A; Tue, 8 Jun 2021 15:57:02 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 297CA4067A; Tue, 8 Jun 2021 15:57:01 +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 958E77F4FE; Tue, 8 Jun 2021 16:57:00 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 958E77F4FE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1623160620; bh=8ZpTllAWObH8c0JQZi7n4z7qsZ9s6Tiq6grwLYY8nFo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=fj3UUPhl58BbEFmEtNCNtpCuUmVGrkvKz8Cr0IcOEmI0jaQvt6/WC76jTjGcs1BXG yxBD26yrydtyCBDWWTY7zn2rrsWn0ZkIOV/lOpof333J4IfbL4FF0dW6Lpwe2IFbMH 5uByFPS+cTijbHB/1O3KSQQFqPtEtYjcHZeh+Klg= 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> <359f754b-6ee3-d3e4-5cfc-06f399db9617@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <5be5ae7d-7e7f-51d0-9bf0-4bd558788ca6@oktetlabs.ru> Date: Tue, 8 Jun 2021 16:57:00 +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-stable] [dpdk-dev] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 6/8/21 3:49 PM, Olivier Matz wrote: > On Tue, Jun 08, 2021 at 03:34:36PM +0300, Andrew Rybchenko wrote: >> 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. > > This function is called on the Rx path from pmd_rx_burst(), so > the application does not have access to the mbuf. > > The software parser that sets the packet type returns either > RTE_PTYPE_L3_IPV4 if there is no option, or RTE_PTYPE_L3_IPV4_EXT > else. The value RTE_PTYPE_L3_IPV4_EXT_UNKNOWN is used by PMDs that don't > know if there are options. I see. What I'm trying to say that there are non obvious assumptions here on rte_net_get_ptype() behaviour which can be changed. May be it makes sense to add comments here to highlight it. > >>> - 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 ? >>>>>> >>>> >>