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 5D093A0C40; Tue, 8 Jun 2021 14:29:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E4D5A410EB; Tue, 8 Jun 2021 14:29:31 +0200 (CEST) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by mails.dpdk.org (Postfix) with ESMTP id 4447440689 for ; Tue, 8 Jun 2021 14:29:31 +0200 (CEST) Received: by mail-wr1-f42.google.com with SMTP id a11so19507776wrt.13 for ; Tue, 08 Jun 2021 05:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ea6zr2Oo+94jWsIM3s8bQjcGECIhSPtYuCj164FMiCU=; b=JTpkujDBKsxsQ3lg/u5kFw+KtzXilSeOHG8FR0HBVpK+Ix9zbhdzGw+r76ATbeY0UO fdcn8LenrqqFEZPjZ7PUxfTkvM2XHYbu5WDkAQWBqzN8c+1y3IbThZUZH9HLZdJLfPCC 4JQURr1OzZNnWdWI+FpH5fOq0izVouGNGCTis7NXS5ZpZnzGQ41uO1Fcjk3ZANfUnoPv bg17ZBqAZ1IWlLWJBSuomqN1bUSfRZ87PkmbhuMGI+Dc8nYzWsa7hR7Uuc7YPYOwt6ZW u3bgVTbI78Ur7meHJGf8mvSfT6yLVL8v4lndJ+EFDerQMAtiC9+YxbuTNDAt0ZifTYlo p8jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ea6zr2Oo+94jWsIM3s8bQjcGECIhSPtYuCj164FMiCU=; b=CemD8e3N1Dau9GEyZW71fOUPNrTJNy1EPOmo3+tQiKLbZ7HK1EA2RWmYPBsRwNwkYj 4XkVGQjg2dU2iMZoeXiJjG8jyiRM/U8kaB7rR7Zl8Cw5VHmJC5oeK92/ABmcigDBuW8K n7LKw0oSByl2xH6qbWJUTvjrZBbtaoD6g7TJtJA21u1zFwWa8jNpMKVv78Y1wI/jpswM i9+KaXdPCBZZ8O+jz1bFevZ8jGOuw/Yt8G8jSv5g9BMXZKsX/yIQriiL2APhTT4+mmFX r6uGWrJOV/vaZ19gsfosvCDx8GQlFOiFMCrvw5ItjqSEb/oVyA+moZRG+bLsdL/QiKUG F/ig== X-Gm-Message-State: AOAM5315TnEHpkdpP8JHVvJZ5eFBXRq1nobis2W3LZINkXlYcbfhf2lJ 8NW0B2RBzw7o3C3leDWD/3SafQ== X-Google-Smtp-Source: ABdhPJxTMYhqID0ZaUyB0N0aa0gHn0FOoQJG+oUae3f6FCOQSwoneo4HTMQOdtrQyxTIlImQRZGnTw== X-Received: by 2002:a5d:4752:: with SMTP id o18mr8367732wrs.323.1623155370936; Tue, 08 Jun 2021 05:29:30 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id g23sm2955442wmk.3.2021.06.08.05.29.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Jun 2021 05:29:30 -0700 (PDT) Date: Tue, 8 Jun 2021 14:29:29 +0200 From: Olivier Matz To: Andrew Rybchenko Cc: Ferruh Yigit , dev@dpdk.org, Keith Wiles , Hongzhi Guo , Morten =?iso-8859-1?Q?Br=F8rup?= , Thomas Monjalon , stable@dpdk.org Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39a8a8bb-d246-3377-607c-3c2387b73fe0@oktetlabs.ru> 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" 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 rte_net_get_ptype(), which cannot return 'RTE_PTYPE_L3_IPV4_EXT_UNKNOWN' - 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 (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 ? > >> >