From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH v2 1/4] ethdev: add Rx offload outer UDP checksum definition Date: Mon, 8 Oct 2018 11:53:01 +0100 Message-ID: References: <20180913134707.23698-1-jerin.jacob@caviumnetworks.com> <601d2413-e148-73c4-e7a5-59f09bd02451@intel.com> <20181008082421.GA3554@jerin> <2218090.RkeNvosNi6@xps> <20181008093741.GA11081@jerin> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "Ananyev, Konstantin" , Andrew Rybchenko , "Lu, Wenzhuo" , "Wu, Jingjing" , "Iremonger, Bernard" , "Mcnamara, John" , "Kovacevic, Marko" , Olivier Matz , "dev@dpdk.org" , "shahafs@mellanox.com" , "didier.pallard@6wind.com" To: Jerin Jacob , Thomas Monjalon Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 4182DDE3 for ; Mon, 8 Oct 2018 12:53:08 +0200 (CEST) In-Reply-To: <20181008093741.GA11081@jerin> Content-Language: en-US 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/8/2018 10:37 AM, Jerin Jacob wrote: > -----Original Message----- >> Date: Mon, 08 Oct 2018 11:04:51 +0200 >> From: Thomas Monjalon >> To: Jerin Jacob , Ferruh Yigit >> , "Ananyev, Konstantin" >> >> Cc: Andrew Rybchenko , "Lu, Wenzhuo" >> , "Wu, Jingjing" , >> "Iremonger, Bernard" , "Mcnamara, John" >> , "Kovacevic, Marko" , >> Olivier Matz , "dev@dpdk.org" , >> "shahafs@mellanox.com" , "didier.pallard@6wind.com" >> >> Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: add Rx offload outer UDP >> checksum definition >> >> 08/10/2018 10:24, Jerin Jacob: >>> From: Ferruh Yigit >>>> On 10/6/2018 1:18 PM, Ananyev, Konstantin wrote: >>>>> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] >>>>>> From: Thomas Monjalon >>>>>>> However, we should re-visit the flag PKT_RX_EIP_CKSUM_BAD. >>>>>> >>>>>> Do we need to block this patch due to the exiting PKT_RX_EIP_CKSUM_BAD >>>>>> definition? >>>>>> >>>>>> I already added the author of the PKT_RX_EIP_CKSUM_BAD flag and ethdev and mbuf >>>>>> maintainers in this list. So what else I need make forward progress >>>>>> on this patch? >>>>>> >>>>>> I think, the definition of PKT_RX_EIP_CKSUM_BAD based on HW capability. It >>>>>> is safe to assume that ALL HW can support CKSUM BAD if the feature is >>>>>> available and hence it is more portable. >>>>> >>>>> Yes, as I remember PKT_RX_EIP_CKSUM_BAD is based on DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM. >>>> >>>> Switching to two bit won't reduce the portability, HW supports only reporting >>>> CKSUM_BAD can set BAD || UNKNOWN. >>> >>> UNKNOWN is not a bit. It is represented as 0. It spec has 2 bit, then >>> driver need to report GOOD as well. >>> >>> Same applies for PKT_RX_EL4_CKSUM as well. >>> >>>> >>>> And I think patch is not blocked by PKT_RX_EIP_CKSUM_BAD, it can be changed >>>> separately, for this patch question is can we represent PKT_RX_EL4_CKSUM_* with >>>> two bits, to have BAD/GOOD/UNKNOWN? >> >> Yes, exact. >> >> PKT_RX_EIP_CKSUM_BAD must be left aside. >> We should just avoid taking it as a reference. >> And we can reconsider its definition later. > > OK. > > IMO, Using 2 bit scheme for tunneled checksum has following performance > issue from driver side. > > Driver need to mark the packet as GOOD. All the HW can support > detection of BAD. That not necessary mean GOOD in case of tunnel packet, > so driver has to detect the packet is tunneled and packet is not BAD > then mark GOOD. Yes UNKNOWN is not a bit, but a state, why don't use it? Why driver has to check it is GOOD? 0x0 => UNKNOWN 0x1 => BAD 0x2 => GOOD 0x3 => ? (invalid perhaps) HW that supports detecting good packets can set BAD || GOOD state, HW can detect only BAD packet can set BAD || UNKNOWN state. If BAD is not set, there is an ambiguity of state, lets clarify it in lower level, if it is UNKNOWN, let application know it is UNKNOWN.