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 438CCA0561; Thu, 4 Mar 2021 11:46:24 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CFBD540684; Thu, 4 Mar 2021 11:46:23 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id BAA8840147 for ; Thu, 4 Mar 2021 11:46:21 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 184F915B3; Thu, 4 Mar 2021 05:46:20 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 04 Mar 2021 05:46: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= lLQGEL6/mkn+Y0rSdp6GtTc7OSA80w2wocaez8+LhlA=; b=J2iImk+IdqqQCcxx MAPPPFSiBoZyZTJX7A2vxMwgTdCqFX3E+1hZ5iZ4+rRwTfNCkrBU+JqDmXYi4N7s AmC/6lspgXPk0OlzhGjtkudSTcrDaZw8vsjKqs7TdCSH2R1/jfbM+1GMTUx0Ksfs YESy55FUKpWyYDBuxXqACcAnKFhV0fViS24TLTyU6stGWgrj/tVf3NzCqOKP6GBT 8o3H8UDWq23nWyd3Od+ljpacF3qP88GlvluciFRvvzDl6Ls4+HJEkJsE18Qd+t/H v0n5UVnvMypsLQZa8cG6qkvQSx3zslmW5VM2gJ1+8iAmMnY8E9a9Q1dVOd/sHXzn Hv0F4g== 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=lLQGEL6/mkn+Y0rSdp6GtTc7OSA80w2wocaez8+Lh lA=; b=RJt5IjK826lXhZOxtUhHxdgrZxkGEX2Lrz55AZvQZi/5Vhoa0fZ1d8FWo YWmLoMgybkEYTKGUMqYzk7kK+hm7ytCJ9hBrEItuhfeRe+bMuqYj0tAITxSJ8Kli B+6pLIUJ1KiOGVhb0qCY6zOWJGOyte3a4Dcn4m2mfOynMNHWxGqbT55t5IU0p3Bq 9ensl5z0wLGLHtZZcOd8WVS+1Dq4wtzlTL8L3OgcL2ScLjdw5QamDHmhczaZMuz5 JXmZRvslWW/nKS5RITzLaoZKeS4H5k0oJ3Mb7cUzD2VizZ8YRq5G+EyPNJcBTYHY 8GaEp6bkJswAByYQBQOahD3mLY/iA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtgedgudejucetufdoteggodetrfdotf 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 431311080054; Thu, 4 Mar 2021 05:46:18 -0500 (EST) From: Thomas Monjalon To: Ori Kam Cc: Slava Ovsiienko , "ferruh.yigit@intel.com" , Andrew Rybchenko , "dev@dpdk.org" , "ajit.khaparde@broadcom.com" , "jerinj@marvell.com" Date: Thu, 04 Mar 2021 11:46:15 +0100 Message-ID: <7146547.nIQmEXas8S@thomas> In-Reply-To: References: <1614541699-99345-1-git-send-email-orika@nvidia.com> <1769565.OWqOAu9aEJ@thomas> 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" 04/03/2021 11:00, Ori Kam: > From: Thomas Monjalon > > 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/ > > > > Sure > > > > 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? > > > > This also relates to your other comments, > Each HW may run different set of checks on the packet, > for example one PMD can just check the tcp flags while > a different PMD will also check the option. I'm not sure how an application can rely on such a vague definition. > > > + * 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? > > > Our HW doesn't support it. > If other HW support it, it should be added. It would be an ABI breakage. Can we add it day one? > > > + 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? > > > It depends on the HW in question. > In our case it checks in case of L3 > the header len, and the version. > For L4 checking the len. If we don't know exactly what is checked, how an application can rely on it? Is it a best effort check? What is the use case? > > > + uint32_t l3_ok_csum:1; > > > + /**< L3 layer checksum is valid. */ > > > + uint32_t l4_ok_csum:1; > > > + /**< L4 layer checksum is valid. */ What worries me is that the checksum is separate but other checks are in a common bucket. I think we should have one field per precise check with a way to report what is checked.