From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DFCDDA04DD; Tue, 10 Nov 2020 18:43:12 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1A2602E8D; Tue, 10 Nov 2020 18:43:09 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id B504DF64 for ; Tue, 10 Nov 2020 18:43:06 +0100 (CET) IronPort-SDR: 4DeGIrxkEzf8FhmWe0QHJ3W1ZF6mA1up/s0hUlzaUDeGlsvMUkBdrE4PPTFQ4F5FzKECsaKZYI AV7zD9FkxHwQ== X-IronPort-AV: E=McAfee;i="6000,8403,9801"; a="166509099" X-IronPort-AV: E=Sophos;i="5.77,466,1596524400"; d="scan'208";a="166509099" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Nov 2020 09:43:01 -0800 IronPort-SDR: yT9CoYJF9Vb2+qOs/54XNynLZTJoJupLPamWVCxT1XHNNQWQyLZIXm1l+m6iXvelofYWq3U3KV oqUvsNhtFCFA== X-IronPort-AV: E=Sophos;i="5.77,466,1596524400"; d="scan'208";a="541420883" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.0.179]) ([10.252.0.179]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Nov 2020 09:42:58 -0800 To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , Michael Pfeiffer , Keith Wiles Cc: dev@dpdk.org References: <20201109142217.115918-1-michael.pfeiffer@tu-ilmenau.de> <98CBD80474FA8B44BF855DF32C47DC35C61415@smartserver.smartshare.dk> From: Ferruh Yigit Message-ID: <22b7290c-7b65-68c8-5eea-1db8f90f78f7@intel.com> Date: Tue, 10 Nov 2020 17:42:54 +0000 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61415@smartserver.smartshare.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] net/tap: Allow all-zero checksum for UDP over IPv4 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 11/10/2020 4:01 PM, Morten Brørup wrote: >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit >> Sent: Tuesday, November 10, 2020 3:47 PM >> >> On 11/9/2020 2:22 PM, Michael Pfeiffer wrote: >>> Unlike TCP, UDP checksums are optional and may be zero to indicate "not >>> set" [RFC 768] (except for IPv6, where this prohibited [RFC 8200]). Add >>> this special case to the checksum offload emulation in net/tap. >>> >>> Signed-off-by: Michael Pfeiffer >>> --- >>> drivers/net/tap/rte_eth_tap.c | 13 +++++++++++-- >>> 1 file changed, 11 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/net/tap/rte_eth_tap.c >> b/drivers/net/tap/rte_eth_tap.c >>> index 2f8abb12c..e486b41c5 100644 >>> --- a/drivers/net/tap/rte_eth_tap.c >>> +++ b/drivers/net/tap/rte_eth_tap.c >>> @@ -303,6 +303,7 @@ tap_verify_csum(struct rte_mbuf *mbuf) >>> uint16_t cksum = 0; >>> void *l3_hdr; >>> void *l4_hdr; >>> + struct rte_udp_hdr *udp_hdr; >>> >>> if (l2 == RTE_PTYPE_L2_ETHER_VLAN) >>> l2_len += 4; >>> @@ -349,10 +350,18 @@ 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) { >>> + if (l4 == RTE_PTYPE_L4_UDP) { >>> + udp_hdr = (struct rte_udp_hdr *)l4_hdr; >>> + if (udp_hdr->dgram_cksum == 0) { >>> + mbuf->ol_flags |= PKT_RX_L4_CKSUM_NONE; >>> + return; >>> + } >>> + } >>> cksum = ~rte_ipv4_udptcp_cksum(l3_hdr, l4_hdr); >>> - else if (l3 == RTE_PTYPE_L3_IPV6) >>> + } else if (l3 == RTE_PTYPE_L3_IPV6) { >>> cksum = ~rte_ipv6_udptcp_cksum(l3_hdr, l4_hdr); >>> + } >>> mbuf->ol_flags |= cksum ? >>> PKT_RX_L4_CKSUM_BAD : >>> PKT_RX_L4_CKSUM_GOOD; >>> >> >> While checking this I stuck with following part: >> >> cksum = ~rte_ipv6_udptcp_cksum(l3_hdr, l4_hdr); >> ... >> mbuf->ol_flags |= cksum ? >> PKT_RX_L4_CKSUM_BAD : >> PKT_RX_L4_CKSUM_GOOD; >> >> >> Is this correct, or am I missing something, can intention be '!' here >> instead of >> '~' ? > > It is correct. The packet's checksum is calculated by rte_ipv6_udptcp_cksum(), and it should be 0xFFFF. The '~' operation makes cksum 0 iff the calculated checksum is 0xFFFF. > Yep, figure that out late, as far as I understand when the checksum value is zero, 'rte_ipv6_udptcp_cksum()' will return the checksum value and when checksum is correct in the packet, function will return 0xFFFF, this is based on checksum calculation, is this right?