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 B30EAA09EF; Tue, 15 Dec 2020 23:05:16 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 06888CA4C; Tue, 15 Dec 2020 23:05:15 +0100 (CET) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by dpdk.org (Postfix) with ESMTP id 6EEDFCA41 for ; Tue, 15 Dec 2020 23:05:12 +0100 (CET) Received: by mail-yb1-f173.google.com with SMTP id y128so765484ybf.10 for ; Tue, 15 Dec 2020 14:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JrbKTHQNXHsVBMBNeg7r5LCHAdivG0/1hibZo5/qCdU=; b=GffE1og449FWZm6zU9+sJFHbts+B9PkvWFsQgfkqrkm47fE+4RLmKpxtJiL97u50rl g9YIvVOXGBF7624GIlYRkCxXqAqen1OX/mvsOQAYQcD505znpNb3ULqSuCP8PKFArujl FsdRUJt5dmJbAmP2bLpN9zrHsoU2DNVLPyrl7wo2wCIgxWXdzTf3JLbQ3yBW9slPmwDe FO29m1Nb18vFhdzysVFkfYDE3q9go12BNfPCaLN+FlqFkrK6UWLSO0fBQN7zq3UNEgsy ZVf9OS0byxD5VPt/VY0G6q2UolpphlyhrqKNRjqS7PLvQbvRQoZ7ABD9az/gRJwIm8mt TRXg== 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=JrbKTHQNXHsVBMBNeg7r5LCHAdivG0/1hibZo5/qCdU=; b=ACvGbWHOkmctjDsmj9T9NSqdSpLU+DHgHDwdZUbb+O+MHWKWTaFD0aBDudTa4lGzVT 9/xDNjcqs1lv96E2m3zEjLV8eMMGATgj9qjKloElQOJgBmEdlyEyNQ2fw/amjM8HWZrF 84F5tjrIR5WibFNk4Bhhoj3flS2p3RbZkXAjCxZ74LIndVWg1jR62NFP6kkUlmOqnsaC GSG8Ywbow7sXBgmuBYaCnH/wOIyFiGoSwNF3p68d0wiG9xyWG+dmqGu4y3VVk0yQGReY /CooE31sboIyIyJDPwAek2er955emVXgwT97KtNxD9TRg4R5QLtcBTPsWLDScjOJ1mAY ITBw== X-Gm-Message-State: AOAM530UVYZjN1nXL7PdaFWOdF/KQPsnSQD/JOg63V6PlMQ7R6ka/plz 9lAKUfYAYgU3gg5m5RLFl1YDExmyrumJ9Rw2nkM= X-Google-Smtp-Source: ABdhPJx5M2mke5zM+pdlBppxQfQ1EUsxKJqMjsdtM90ezCJaSg0WoKCNEz/FJayLqqyNw5jTgEu5g1bt4iGcv/D3bso= X-Received: by 2002:a25:7c43:: with SMTP id x64mr46308363ybc.267.1608069910860; Tue, 15 Dec 2020 14:05:10 -0800 (PST) MIME-Version: 1.0 References: <20200917140503.GS21395@platinum> In-Reply-To: From: Lance Richardson Date: Tue, 15 Dec 2020 17:05:00 -0500 Message-ID: To: Lance Richardson Cc: Olivier Matz , Ferruh Yigit , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" 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 Mon, Dec 14, 2020 at 12:41 PM 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.) > > Regards, > > Lance > Apologies for the corporate-enforced email footer, picking back up on a personal email account. I'm not sure whether this is an rte_mbuf API question or a PMD implementation question, likewise not sure whether it should be directed to Olivier or Ferruh or someone else. Any advice is appreciated. Thanks, Lance