From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 28A7EA0548; Sun, 28 Feb 2021 21:14:26 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BA2B222A25B; Sun, 28 Feb 2021 21:14:25 +0100 (CET) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id AF9E322A23D for ; Sun, 28 Feb 2021 21:14:23 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 33175B27; Sun, 28 Feb 2021 15:14:20 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 28 Feb 2021 15:14:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= KSmOn5L1qoCO7KMgY0Gtf12fWlTpheAns18r2U5PIAM=; b=bGCNZrBkIXkRMFIS HBzjuNBmslcDfp6eCoWswZ4UguyU1HCAT9TE29Vp98nSCoyec6scVruHkS3eEAQT yXDYh1ay9Mf+zgRe2TaEDqzw+vbW8KFVlsCNLNSTQ2QnHqbbNQrIo/hSgCBUWByC ixdFCN8xYpRPln27ihF+C9/Yv/9l10zvlmgyPCOJONkJX2YbLplYkxBSNYrVWLhQ KpdiGw43QxA1zniMk/cIV85c5plPCz+7t6e5xKswCnGb06U4+ee3gXfj2MJ2/Bse s/LV6Awx1uvgRZobfPxJDX0ENGh6XrTUlD5/q7RgdkePYrWpWB6V5Eue9FrQ/LCz HL9aLg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=KSmOn5L1qoCO7KMgY0Gtf12fWlTpheAns18r2U5PI AM=; b=qL2k1AFm+d3j2svpcqE5x7gKZqS+S0ld5osand9PQONdiYo7nyQNl7eOh dkVFWvFK6en7OoTPw0uiGmdKWQ/iyN9ZZNtxVHvmQOkmX26OEFwoQbj33rIigMiB oKBXQB/5WTsI8XrfFVWmnctjK00+yNynPg8krCCimguz+eKnNEF6ZJNeu30X1KjE CtJhw/kz0x1O5mzdNmmh1qBYp0r+T3obuTiuVljmWEB2gM8dgHx/dOUNGZpzjLb9 BBkrlIqMCsqkIyvjchc8SMa8LR1+DMw1WPXANd2YbinwS8QaQffrLNvLiMm0rcYt vthtlIlf7kWUf6euEsQZc4Jk13rQw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrleeigddufeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BD21C108005F; Sun, 28 Feb 2021 15:14:17 -0500 (EST) From: Thomas Monjalon To: Ori Kam Cc: viacheslavo@nvidia.com, ferruh.yigit@intel.com, Andrew Rybchenko , dev@dpdk.org, ajit.khaparde@broadcom.com, jerinj@marvell.com Date: Sun, 28 Feb 2021 21:14:16 +0100 Message-ID: <1769565.OWqOAu9aEJ@thomas> In-Reply-To: <1614541699-99345-1-git-send-email-orika@nvidia.com> References: <1614541699-99345-1-git-send-email-orika@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC] ethdev: add sanity packet checks X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 28/02/2021 20:48, Ori Kam: > Currently, DPDK application can offload the checksum check, > and report it in the mbuf. > > However, this approach doesn't work if the traffic > is offloaded and should not arrive to the application. > > This commit introduces rte flow item that enables s/rte flow/rte_flow/ > matching on the checksum of the L3 and L4 layers, > in addition to other checks that can determine if > the packet is valid. > some of those tests can be packet len, data len, > unsupported flags, and so on. > > The full check is HW dependent. What is the "full check"? How much it is HW dependent? > + * RTE_FLOW_ITEM_TYPE_SANITY_CHECKS > + * > + * Enable matching on packet validity based on HW checks for the L3 and L4 > + * layers. > + */ > +struct rte_flow_item_sanity_checks { > + uint32_t level; > + /**< Packet encapsulation level the item should apply to. > + * @see rte_flow_action_rss > + */ > +RTE_STD_C11 > + union { > + struct { Why there is no L2 check? > + uint32_t l3_ok:1; > + /**< L3 layer is valid after passing all HW checking. */ > + uint32_t l4_ok:1; > + /**< L4 layer is valid after passing all HW checking. */ l3_ok and l4_ok looks vague. What does it cover exactly? > + uint32_t l3_ok_csum:1; > + /**< L3 layer checksum is valid. */ > + uint32_t l4_ok_csum:1; > + /**< L4 layer checksum is valid. */ > + uint32_t reserved:28; > + }; > + uint32_t value; > + }; > +};