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 7A613A0567; Tue, 9 Mar 2021 10:11:12 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0490A22A443; Tue, 9 Mar 2021 10:11:12 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 06D134069D for ; Tue, 9 Mar 2021 10:11:11 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7FD875C0115; Tue, 9 Mar 2021 04:11:09 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 09 Mar 2021 04:11:09 -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= FrP2lcpDJ/jBSg6dBw7LM3azaLGdO8oZWUHT+LrRLOU=; b=zkuoSOdHTQcysXRy 7GoDOLyGBtua1NU960EFievEp5ogfSIEoDxIo85u6kUXDFczC1uxsFf29B2VviVC UJFeh+aLoHuBJsW3aOfn5XQNH7JxlZQxAEQsmgTqdp5ef1F2onA6plL0KplD7wAn XJ+WMRcc7F7oXNawpwQOGOQ8tELKDeEE0kVFZeu9WoTlNKpe6L8zdrmluiyL9n/S f0KgK+Vk8y2nMLrH7LO09S/bMDFvTSjC45dsiq2UCi759CWPHSJcBxbqPYZE8I0C M/xhqrDw359up0hdIryO6pbkW5GLDcXWO/C+OfOv/g6nCFR/uYNrF8/bv0BEQo1K LDCbAA== 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=FrP2lcpDJ/jBSg6dBw7LM3azaLGdO8oZWUHT+LrRL OU=; b=PXjiLpXZ2ZEOZHe1hFBX6CQZ1xju8cjoi+JFecK4tkR4L4RYxWPJW73kk XsQl3r8KqYs9mHIRFTC203Rj+MURf5BJXKkIoTLAapnpnco9tcirn4pnLcfzoEs7 G5OAR8VOjBmZa4GurKShwcrZqRa95bbAgoVWUm9zFFQlBwmqcOgl94WCobkRVM3b 4BIa+vHDhZCcmcghvZkYnNNFVeGQ+F9h8SliCNv3tLcE7mk9Uj28qcWdnrQuVT+C Cjsp7F3GorO2gORxp5uKWD/XsCjQf/vjW4b2kR+SqBOvUzoTW9wpctURUpz8uhZf tLRqpdPQHDBAFsvAT/pcwO7v+RRqA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudduhedguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth 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 8F994108005F; Tue, 9 Mar 2021 04:11:07 -0500 (EST) From: Thomas Monjalon To: Ori Kam , Andrew Rybchenko Cc: viacheslavo@nvidia.com, ferruh.yigit@intel.com, dev@dpdk.org, ajit.khaparde@broadcom.com, olivier.matz@6wind.com, jerinj@marvell.com Date: Tue, 09 Mar 2021 10:11:05 +0100 Message-ID: <6096492.0E5FNQikke@thomas> In-Reply-To: <9e1388ac-27f7-aa1b-19e8-6acb6dfc3498@oktetlabs.ru> References: <1614541699-99345-1-git-send-email-orika@nvidia.com> <9e1388ac-27f7-aa1b-19e8-6acb6dfc3498@oktetlabs.ru> 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" 09/03/2021 10:01, Andrew Rybchenko: > On 2/28/21 10:48 PM, Ori Kam wrote: > > 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 > > 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. > > > > Signed-off-by: Ori Kam > > In general, I strongly dislike the approach. If such checks are required, > it must be done per item basis. I.e. we should add non-header boolean > flags to IPv4, TCP, UDP etc items. E.g. > > struct rte_flow_item_ipv4 { > struct rte_ipv4_hdr hdr; /**< IPv4 header definition. */ > bool hdr_checksum_valid; > }; > > Also it will allow to filter by packets with invalid checksum as well and > redirect to dedicated Rx path or drop and/or count etc. +1 I think the only drawback of this solution is for HW giving a global check status without knowing which header is valid or invalid.