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 3F2D2A04DD; Tue, 10 Nov 2020 16:56:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B41412BAA; Tue, 10 Nov 2020 16:56:17 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id ED3542B9D for ; Tue, 10 Nov 2020 16:56:14 +0100 (CET) IronPort-SDR: Opmhz52wnOUDV+sTw8wsr6wrjE+Iobdr3ulSc2mEC9ZhrRLqigp77m5+l2I85L56/b4HmrDXJz CNugLGGkOODQ== X-IronPort-AV: E=McAfee;i="6000,8403,9801"; a="254707581" X-IronPort-AV: E=Sophos;i="5.77,466,1596524400"; d="scan'208";a="254707581" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Nov 2020 07:56:11 -0800 IronPort-SDR: 7+p2bCA5bKGMR0kh0TI8cYEMZ8HC9jmvMDvfl7HhLNRIcAy5agfWLccfD6aMtuRwcjwlJ9VzlV xrFnHsNbHvCA== X-IronPort-AV: E=Sophos;i="5.77,466,1596524400"; d="scan'208";a="541374641" 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 07:56:10 -0800 From: Ferruh Yigit To: Michael Pfeiffer , Keith Wiles Cc: dev@dpdk.org References: <20201109142217.115918-1-michael.pfeiffer@tu-ilmenau.de> Message-ID: <6a6cdf96-3d76-6afb-d8ca-0693c09744ca@intel.com> Date: Tue, 10 Nov 2020 15:56:05 +0000 MIME-Version: 1.0 In-Reply-To: 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 2:46 PM, Ferruh Yigit wrote: > 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 > '~' ? This seems correct, this is related to what cksum functions return and how to verify cksum, I will proceed with the patch.