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 8B273A04B6; Tue, 13 Oct 2020 09:51:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 352151D9FF; Tue, 13 Oct 2020 09:51:22 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id CF9A51D9C9 for ; Tue, 13 Oct 2020 09:51:20 +0200 (CEST) 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 8C6C87F48B; Tue, 13 Oct 2020 10:51:19 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 8C6C87F48B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1602575479; bh=iRooBpI509kxJ4aRNdSsgUYUpd92IFIpL0evMBYVI84=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=H+eJgokVA3XHkSTSIy0ZXzbpWVlmxR9zEzH3bo5GxtsbUUKBHUkNKJ+KL8rQOfyVB 38GT9wAXc46eXlKwi+mzthL3PlmV2owU8LqPraO5c1YWjAAYfvyzmDPAQ6RO/wO/iP sb/z2B/vB2HkRqq+bMTovGNJYISOkSZNYd1bvqw8= To: Nipun Gupta , "dev@dpdk.org" Cc: "thomas@monjalon.net" , "ferruh.yigit@intel.com" , Hemant Agrawal , Sachin Saxena , Rohit Raj , "jerinjacobk@gmail.com" , "stephen@networkplumber.org" , "asafp@nvidia.com" References: <20200831075333.10135-1-nipun.gupta@nxp.com> <20201009131331.5897-1-nipun.gupta@nxp.com> <794e2ad5-35a4-1b84-2ce4-0df059806f39@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <3d279b35-1818-98a0-fb63-c2bf5d9e418b@oktetlabs.ru> Date: Tue, 13 Oct 2020 10:51:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.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] [PATCH 1/3 v3] ethdev: add rx offload to drop error packets 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" On 10/13/20 10:36 AM, Nipun Gupta wrote: > > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Tuesday, October 13, 2020 12:52 PM >> To: Nipun Gupta ; dev@dpdk.org >> Cc: thomas@monjalon.net; ferruh.yigit@intel.com; Hemant Agrawal >> ; Sachin Saxena ; Rohit >> Raj ; jerinjacobk@gmail.com; >> stephen@networkplumber.org; asafp@nvidia.com >> Subject: Re: [dpdk-dev] [PATCH 1/3 v3] ethdev: add rx offload to drop error >> packets >> >> On 10/12/20 3:22 PM, Andrew Rybchenko wrote: >>> On 10/12/20 2:30 PM, Nipun Gupta wrote: >>>>> -----Original Message----- >>>>> From: Andrew Rybchenko >>>>> Sent: Monday, October 12, 2020 1:32 PM >>>>> To: Nipun Gupta ; dev@dpdk.org >>>>> Cc: thomas@monjalon.net; ferruh.yigit@intel.com; >> arybchenko@solarflare.com; >>>>> Hemant Agrawal ; Sachin Saxena >>>>> ; Rohit Raj ; >>>>> jerinjacobk@gmail.com; stephen@networkplumber.org; asafp@nvidia.com >>>>> Subject: Re: [dpdk-dev] [PATCH 1/3 v3] ethdev: add rx offload to drop error >>>>> packets >>>>> >>>>> On 10/9/20 4:13 PM, nipun.gupta@nxp.com wrote: >>>>>> From: Nipun Gupta >>>>>> >>>>>> This change adds a RX offload capability and configuration to >>>>>> enable hardware to drop the packets in case of any error in the >>>>>> packets such as L3 checksum error or L4 checksum. >>>>>> >>>>>> Signed-off-by: Nipun Gupta >>>>>> Signed-off-by: Rohit Raj >>>>>> Reviewed-by: Asaf Penso >> >> Thinking a bit more about it I agree with Thomas idea that >> it should be flow API based solution in fact. >> Drop is just a one of possible actions to be done with >> packets with bad checksum on one or another layer. >> Such packets could be redirected to a slow path >> (dedicated queue or port ID (PF, VF)). >> It is just a missing feature in various layer >> pattern match to say if we want to proceed with packets >> with only good or only bad chehcksum (or we don't care >> as we do right now). Exact match for checksums is hardly >> useful except UDP with zero checksum case. > > I would think of it applicable to both, i.e. it could fit in config option > as well as in flow (e.g. RSS we also have as part of both config and flow). > Having this in flow would increase usage like redirecting as you mentioned, > and having in the config will increase utility when simple config like RSS is > used without flow API's. I dislike the idea to have it on both layers. It adds conflicts by design. It should be no duplication. That's why mirroring API is deprecated and will be removed since we have the functionality via flow API now.