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 D7D48A09F6; Fri, 18 Dec 2020 10:27:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9B031CA2C; Fri, 18 Dec 2020 10:27:30 +0100 (CET) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by dpdk.org (Postfix) with ESMTP id E8ECACA28 for ; Fri, 18 Dec 2020 10:27:27 +0100 (CET) Received: by mail-wr1-f45.google.com with SMTP id m5so1358572wrx.9 for ; Fri, 18 Dec 2020 01:27:27 -0800 (PST) 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=VQ7OzvwX9bsXF8wWengXfyAEp0oC7dZ8se/kMIjz4W0=; b=EGHoOZWgsxjN8ERv+us5IAw7wL41MYorKPkR7V2dZCEKKRc8LxczwVrKAO033GYkhe 48/pTa+mj18APCt6pgTaQPYKbnMbSq/tzN6DTp1cmPSXS8EO0frJSn49bZecIT5wWQoT r9rBDRG71izfj38tDbT22ZgHdpqEnz9qNp7pYzO1uScCF4TO75CO7vH+BfiW3UXcAI0/ u6XcaJeTDCeI9HTjQCzJFlH+lj8cZP8i8zJPDinJyGuAlOjh40R82JmfsVbIurFaOGJ3 ssHapAF6mxx/IyOGqqQ71IvVuv0M/druHW5zrMG0sF2lgWRvE4yqYpwT8R0vJLI47uXS CVQQ== 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=VQ7OzvwX9bsXF8wWengXfyAEp0oC7dZ8se/kMIjz4W0=; b=t90QWcN6x8bSp1nw1+qRs2OeOoEonjcVcEv3X/NftUJQb+I5azLU8lnnX2eaCyDnSa xtdnHCtmSz9sbd0ZcYwBy6V/Mk5pksCCuwBstEQidwJiGgq+kxX6ZCqu5EeRjFII8XUp Aq8Iw2ZEHnAN15HN+6Map1xChvbj8YGTX5yb/LvL3n5m6m0QT20zeH6Og87ACFtTU25O nXDeMLgUiZYqXcF3RuYR9rXnzgZRFYTNgtDNuDsOuZ/S/1Od32jAU1YaZN9pQ2DHxdhN DGBZPZco8OuMIb6ghE1VD9ZRjTl9+KKkKb+qx4bfJcHh8q1LrGAGLhgar3VfYdvLF8wf sliQ== X-Gm-Message-State: AOAM531BDRTFDoHQYMOyWg9HI6JPXVKtwvfIQ3/rnfmbMKT4X0Nmk/yU A7nX4QHTBT+Y2dG1YVeXjAeVRA== X-Google-Smtp-Source: ABdhPJwKkcvFj+tSdurWE3x4FlOZgY4bKxwahrfTeGeU5eDi9kgSb4UB4uil6gDdK5j0wegfxfuVjA== X-Received: by 2002:adf:eb05:: with SMTP id s5mr3251751wrn.333.1608283646637; Fri, 18 Dec 2020 01:27:26 -0800 (PST) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id b200sm11404642wmb.10.2020.12.18.01.27.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Dec 2020 01:27:25 -0800 (PST) Date: Fri, 18 Dec 2020 10:27:25 +0100 From: Olivier Matz To: Lance Richardson Cc: Ferruh Yigit , dev@dpdk.org Message-ID: <20201218092725.GA2631@platinum> References: <20200917140503.GS21395@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] question regarding rx checksum offload flags 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" Hi Lance, On Mon, Dec 14, 2020 at 12:41:34PM -0500, Lance Richardson wrote: > On Thu, Sep 17, 2020 at 10:05 AM Olivier Matz wrote: > > > > Hi Lance, > > > > On Mon, Aug 24, 2020 at 04:11:45PM -0400, Lance Richardson wrote: > > > I was looking for some clarification regarding how rx checksum > > > flags should be set for tunnel packets having both inner and outer > > > IP/L4 headers. > > > > > > Based on comments in rte_mbuf_core.h, it seems to me. that the > > > inner (encapsulated) IP header checksum status should determine > > > which of these goes into ol_flags: > > > PKT_RX_IP_CKSUM_UNKNOWN > > > PKT_RX_IP_CKSUM_BAD > > > PKT_RX_IP_CKSUM_GOOD > > > PKT_RX_IP_CKSUM_NONE > > > > > > Similarly, the L4 checksum status should determine which of these > > > goes into ol_flags: > > > PKT_RX_L4_CKSUM_UNKNOWN > > > PKT_RX_L4_CKSUM_BAD > > > PKT_RX_L4_CKSUM_GOOD > > > PKT_RX_L4_CKSUM_NONE > > > > > > The IP header checksum status for the outer IP header should determine > > > whether this flag is set in ol_flags: > > > PKT_RX_EIP_CKSUM_BAD > > > > > > And for UDP-based tunnel encapsulations, the outer L4 checksum status > > > should determine which of these goes into ol_flags: > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN > > > PKT_RX_OUTER_L4_CKSUM_BAD > > > PKT_RX_OUTER_L4_CKSUM_GOOD > > > PKT_RX_OUTER_L4_CKSUM_INVALID > > > > > > Finally, the checksum status of inner headers should have no influence > > > on PKT_RX_EIP_CKSUM_BAD or PKT_RX_OUTER_L4_CKSUM_*, and > > > likewise the checksum status of outer headers should have no influence > > > on PKT_RX_L4_CKSUM_* or PKT_RX_IP_CKSUM_*. > > > > > > Is this correct? Apologies for such a basic question, but I'm having trouble > > > correlating the above with implementations. > > > > > > Thanks and regards, > > > Lance > > > > The PKT_RX_EIP_CKSUM_BAD flag was added by these commits: > > > > https://git.dpdk.org/dpdk/commit/?id=c22265f6fd4cdcac9ee1b4970e4af8459d267516 > > https://git.dpdk.org/dpdk/commit/?id=d909af8f72ca3f8ab4fe1942abfb4f53e15ff8bc > > > > First, to be honnest, I don't think this API is the right one. From a software > > stack point of view, it would have been more logical to have PKT_RX_INNER_* > > flags instead of outer. > > > > That said, your understanding looks correct to me. I think this is the > > expected behavior when the DEV_RX_OFFLOAD_OUTER* capability is enabled. > > > > If the capability is not set, only the PKT_RX_IP_CKSUM* and > > PKT_RX_L4_CKSUM* flags may be set, and they reference the first layer. > > > > Regards, > > Olivier > > Hi Olivier, > > I've been thinking about how to address this for the bnxt PMD which always > reports PKT_RX_OUTER_L4_CKSUM_* and PKT_RX_EIP_CKSUM_BAD > regardless of whether DEV_RX_OFFLOAD_OUTER_UDP_CKSUM or > DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM are enabled. > > One option would be to modify the PMD to respect the outer UDP and > outer IPv4 checksum offload configuration. Since the mapping of hardware > checksum status to mbuf checksum status is table-based, this would add > very little overhead to the packet handling path, but it would add some > (a larger table would be required, and the index would need to include > the tunnel/non-tunnel status of the packet). > > Another option would be to modify the PMD to force the outer UDP and > outer IPv4 checksum offloads to always be enabled (there is at least > one existing PMD that currently does this). > > The second option should be the least disruptive to existing users, and > would require the least effort to implement, but will it be an acceptable > approach going forward? (If not, it seems the first option would be the > right one to choose.) I think the first option is the right one. It matches the behavior of other drivers. Regards, Olivier