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 8903BA04BB; Tue, 6 Oct 2020 10:10:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6EA5325B3; Tue, 6 Oct 2020 10:10:17 +0200 (CEST) Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id 51D8D1C01 for ; Tue, 6 Oct 2020 10:10:15 +0200 (CEST) Received: by mail-wm1-f66.google.com with SMTP id f21so1941343wml.3 for ; Tue, 06 Oct 2020 01:10:15 -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:user-agent; bh=5lfzGtVLgB4by/ZGMbEcb5Jpk2SSYKXLh2yYnsDIA/E=; b=FY4nfg+x1YyhKXzr/+NcTFaM5AjLt0rlaxak1DQcFNrme7fNQJDIaXoUmPBev9v3Ol f19TAMuxChleSXVUQKpTR3VVhfRPqL9VfhbnrpL0J895zlvECLCsAbpjLQmudnN1BRRF 7wXaGOFkPPKY13YIlz7QGbqaJu67Jr3qXHrCQc9V5uPeenkVOlpa6qk3VKBjU6BVZdiv bvBVvR+cfmMWz2MfTD43nho6ZHbIpV5qJs1Oh8YdfMCoDtxfLgnh8/Mq65p+zF3aVgAJ uisw7OCNW1HOyb16HtNA3bwoWjqanXnCiBll5CThWu7VV+qkahr3aJYTpvVlmP3dHjvx h3jg== 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:user-agent; bh=5lfzGtVLgB4by/ZGMbEcb5Jpk2SSYKXLh2yYnsDIA/E=; b=KOAWcGzWXtL6qsNcpcISYdGV6PPwxeimgvhvNw/4BQTKQaH9WRZZZDGuhZuy/zISxo xpiMxh8L3kZKp5oNleY2rENkil3SZ4mUzdoFuPAGIfA0SdyPJNhDhQsCKddbUHXqbxwc aE3JjiGTP4Scx3GBq6ifxaWIv3J3xD77kAqnM8oV6EQFFdHpm7YBE8f+mtXefwK+nSFM uwUFwZbcvA/eWVQq8awsCL9po+baeEmC8e1FIC05jcswTRecLduWeMOsYn4oP4GTS7A7 RttLpsYFvXCGbfjOvBmvtryeBfZ+PUJvS+jbgxFv5M603sMV1l2VA1v1xtX7+g97SVW+ 1Waw== X-Gm-Message-State: AOAM530DU59qFLOMmBK9wRzeOA+2HutDAvCG8P5LWZDZnwaSz3MMfJWm ZpfoyOmSDOgZe7mAoq/JurvdQnFUlNsO4IKj X-Google-Smtp-Source: ABdhPJz0LKKNEd2auHYH6LTGAyoX7WSmwuj1WRru/TkYcNNKwh+8BNLgw0mmDmSN7Guq+0r4XNr2yA== X-Received: by 2002:a7b:c0d8:: with SMTP id s24mr3387900wmh.156.1601971815025; Tue, 06 Oct 2020 01:10:15 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id s6sm3234749wrg.92.2020.10.06.01.10.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2020 01:10:14 -0700 (PDT) Date: Tue, 6 Oct 2020 10:10:13 +0200 From: Olivier Matz To: Stephen Hemminger Cc: Thomas Monjalon , Michael Pfeiffer , Andrew Rybchenko , dev@dpdk.org Message-ID: <20201006081013.GE21395@platinum> References: <20200821113210.307175-1-michael.pfeiffer@tu-ilmenau.de> <20200901094755.561661-1-michael.pfeiffer@tu-ilmenau.de> <7417467.3Ncg9TYYCI@thomas> <20201005193945.19aebfb5@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201005193945.19aebfb5@hermes.local> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v2] net: calculate checksums for packets with IPv4 options 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 Mon, Oct 05, 2020 at 07:39:45PM -0700, Stephen Hemminger wrote: > On Tue, 06 Oct 2020 00:55:19 +0200 > Thomas Monjalon wrote: > > > > On 9/1/20 12:47 PM, Michael Pfeiffer wrote: > > > Currently, rte_ipv4_cksum() and rte_ipv4_udptcp_cksum() assume all IPv4 > > > headers have sizeof(struct rte_ipv4_hdr) bytes. This is not true for > > > those (rare) packets with IPv4 options. Thus, both IPv4 and TCP/UDP > > > checksums are calculated wrong. > > > > > > This patch fixes the issue by using the actual IPv4 header length from > > > the packet's IHL field. > > > > > > Signed-off-by: Michael Pfeiffer Acked-by: Olivier Matz > > > - cksum = rte_raw_cksum(ipv4_hdr, sizeof(struct rte_ipv4_hdr)); > > > + cksum = rte_raw_cksum(ipv4_hdr, (ipv4_hdr->version_ihl & 0xf) * 4); > > > > Truly naive questions: > > - doesn't it deserve a static inline function rte_ipv4_hdr_len()? > > Makes sense to have that. +1 However it could be in another patch: there are ~15 places where it could be replaced in dpdk.