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 ADF33A09E9; Mon, 14 Dec 2020 18:41:49 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 22A2029AC; Mon, 14 Dec 2020 18:41:48 +0100 (CET) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) by dpdk.org (Postfix) with ESMTP id EC2241F1C for ; Mon, 14 Dec 2020 18:41:45 +0100 (CET) Received: by mail-ot1-f51.google.com with SMTP id f16so16514400otl.11 for ; Mon, 14 Dec 2020 09:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3L+Zjfqu91nR+S1aNmvkeRnqnrPnhdrdiJIOneW+4PE=; b=N8YkMo7dLYfJ439EJ7YCoeUlmrpPjYauEdo6ugYIC8y5EXynFKEPkhm9TCX3zLXUwh Re7f57zi1ZLYINGO5MmKq2PTHSSixOSBGgQB1kCXgIDlQuh01s1WOJHnrPXNDe3SI3iw BSfEu0jEGmZEhClOJF2VXtfYPL5xXYre8Vwug= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3L+Zjfqu91nR+S1aNmvkeRnqnrPnhdrdiJIOneW+4PE=; b=RfOOzcdRggSgnfdgFZdqbnYKmP1mE/Yah/iPupfh1A8GeRym++wUhB/YgPGf6SOmq1 mhsNUDoA/N223EJdRxPtwa7Cc4+J0A0b0pzZMnSA1EvtjW6bIJGflP5QrhxNsqOT5Bf4 /Pxb5YkXkB7dLiEqG8+/BffwIE2/jSSoMmAKBi9/g01oOfhe0AgIhWJn5M1JnYbcxDmv gt7Zdl/baK2kPqQ7AC6RK9vhmHR8O3d9cwTpK75/dsw98hrr7Vzs61spr6i6NBzf6Shr w+I0fgaJBsAsBJqUZJ2TnuKvyAfurBnXTQNN229mVNJXG+JrNr1cMq7e3A/I4px1es0S lHTg== X-Gm-Message-State: AOAM532kcTVMERSuk7vNiOUES46iOlrrQinRZ4eVqp7DJF7dB0HBB9ny KGeR944lk4QRHCzBpi7s5s06tcPEmbzGJiDbT0oXlZ6vEx9Ed+TcJtwho2QdtKLXvHt5I4C9q3c AiUkQYUiLhg== X-Google-Smtp-Source: ABdhPJxhpPhI3NTbtyAxOK52zW+neKApT6HvgYVmx42uwYq3lxIaBfYMPUc4R2vL1ZeKuWK1R2J6rB20bN0Af5vinEQ= X-Received: by 2002:a9d:6642:: with SMTP id q2mr20418016otm.172.1607967705053; Mon, 14 Dec 2020 09:41:45 -0800 (PST) MIME-Version: 1.0 References: <20200917140503.GS21395@platinum> In-Reply-To: <20200917140503.GS21395@platinum> From: Lance Richardson Date: Mon, 14 Dec 2020 12:41:34 -0500 Message-ID: To: Olivier Matz , Ferruh Yigit Cc: dev@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" 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.) Regards, Lance -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.