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 04231A0567; Tue, 9 Mar 2021 16:27:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 67D624069D; Tue, 9 Mar 2021 16:27:43 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 9F7874068A for ; Tue, 9 Mar 2021 16:27:42 +0100 (CET) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 0DEC47F4DA; Tue, 9 Mar 2021 18:27:42 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 0DEC47F4DA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1615303662; bh=z75rJH5EoVwIlIZjcXQPTHSbaJ3ivh4iZ4VaBA27oiA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=TzOyWfNinRYghJVgWX+h3eKpHSteX6h5UTPpNZJy6j5Tk8gsm7C08VQDV3I+Dmgt1 BY6JsAw4886gbx0kJH02J1BpL2bsE9E761g8UlJrFL+bXv2nmNvbTAH+kPs+NcUAhv rDpRuI+8X6ZHXOU/X594rHXwPYT2yw3DzyRCI4dA= To: Ori Kam , NBU-Contact-Thomas Monjalon Cc: Slava Ovsiienko , "ferruh.yigit@intel.com" , "dev@dpdk.org" , "ajit.khaparde@broadcom.com" , "olivier.matz@6wind.com" , "jerinj@marvell.com" References: <1614541699-99345-1-git-send-email-orika@nvidia.com> <9e1388ac-27f7-aa1b-19e8-6acb6dfc3498@oktetlabs.ru> <6096492.0E5FNQikke@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <057b06ac-6c52-3f21-9e2f-cfdd66651342@oktetlabs.ru> Date: Tue, 9 Mar 2021 18:27:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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" On 3/9/21 6:08 PM, Ori Kam wrote: > Hi > >> -----Original Message----- >> From: dev On Behalf Of Thomas Monjalon >> Sent: Tuesday, March 9, 2021 11:11 AM >> Subject: Re: [dpdk-dev] [RFC] ethdev: add sanity packet checks >> >> 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'm not sure I understand your comment, also according to the proposed > RFC we can redirect to the correct path. > >> I think the only drawback of this solution is for HW giving a global >> check status without knowing which header is valid or invalid. >> > Like Thomas remark the main drawback with adding the valid to each > of the items is that, it forces the application to have detected rule per > each type, which will make the SW logic more complex. > Also this may have performance impact on the packets and on the > number of flows. > If we try to match on something which is a part of the packet header X, it must be done in a flow item which corresponds to protocol X. Otherwise, we have two items which overlap. Also approach suggested in RFC break networking protocol layering and features of different layers are mixed in one item. What will you when you need to support tunnels? Add inner/outer fields? Sorry, it is ugly. If valid controls are added in protocol items, no specific efforts are required for tunnels. Also approach suggested in RFC requires very careful definition what happens if a packet does not have corresponding layer but matching on valid or invalid checksum is requested. IMHO a vendor HW limitations are out-of-scope of the generic API definition. May be one day I will regret about these words, but I'm still sure that from API point of view solution suggested by me above is better.