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 D4188A04BB; Thu, 17 Sep 2020 16:05:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BDF671D663; Thu, 17 Sep 2020 16:05:06 +0200 (CEST) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by dpdk.org (Postfix) with ESMTP id 46FB41D65C for ; Thu, 17 Sep 2020 16:05:05 +0200 (CEST) Received: by mail-wm1-f41.google.com with SMTP id k18so2187760wmj.5 for ; Thu, 17 Sep 2020 07:05:05 -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=kXscOpOc9pOC2DNQO+JSqq1Fm9NlNmiN/GvuDVTQUDA=; b=O0OeSZaSSnWMRQwb1YVFpteSo1OfgDTjc/kzbjnbZw3x3MAX0aOuWo2vJNk+1LN3Sa h6u5SDSs5v9Mj9INeJJuSoFwhe9W7Ie/MOz/n2SNd2Ksd8G1w+lNScDntIjsAkIkK7l3 jw6NyZavik+JHqWV/hh5EfZI1RXT+qEarSPu05HEtap2cH3tXJSTKmkY+LQwsc87TVIA wC6Fj7YS2bEOcTVaVMJPXFSYI0WXPaI48lxBC+ZIZq90sdCWnqlUINyucml0ECbYFWz3 gtg8vDmYVh2R9WsmxRXpopBB4CNq5en5lDXXj74jWjwEBkz8XVgrrZcK8hP8O7qFeHT8 6OWQ== 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=kXscOpOc9pOC2DNQO+JSqq1Fm9NlNmiN/GvuDVTQUDA=; b=nmQDPueS8UQ0gAToT8bQG4rv/022rvYKBMRd3QAtSedOfkDkq2A6XGNZ/eZJbqdS9P /VPPZt1zQZE1JRd1mQyY+Ebq74MEKLJYxPWLVxfl2Kv0uaj2hjvESGCJiB7pL/fHQqOH 5nK3t+8S2aQqC/GkR8lCQj8Ig42P7HmgK+T911en2CafRTXAR0sGrTrmy6cGLlTk94Ac nJ/QPecLpOWZ5dDSNd0KpgPPiZYNv3Xw6LBIQ03czTXdfoOkZzULrS+mN+bu8fePae/x v1yt6zDz47Vg5ooACNo5j/zCMhFF4uXanFaj8jOC/xcqwbCfXpEVfrfPS2WfzTNttI8Q WPcA== X-Gm-Message-State: AOAM531JhkY9X6cvj3wwZ35eKb+D2xg/wfm1cz1AlDk5R2sMFcsO2Siv Ut9IEOfXNlJ+Gq+e1dRrrKghDQ== X-Google-Smtp-Source: ABdhPJxmDbnDG/h21ZqeZeiiJXoknYTsxKTf/3UjEreL90N+1LdaDjojjv5Avydgtv9M6cOmiXrqzw== X-Received: by 2002:a1c:e3c3:: with SMTP id a186mr10945429wmh.189.1600351504894; Thu, 17 Sep 2020 07:05:04 -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 n4sm10682851wmc.48.2020.09.17.07.05.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Sep 2020 07:05:04 -0700 (PDT) Date: Thu, 17 Sep 2020 16:05:03 +0200 From: Olivier Matz To: Lance Richardson Cc: dev@dpdk.org Message-ID: <20200917140503.GS21395@platinum> References: 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, 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