On 10/8/2018 10:37 AM, Jerin Jacob wrote: > -----Original Message----- >> Date: Mon, 08 Oct 2018 11:04:51 +0200 >> From: Thomas Monjalon <tho...@monjalon.net> >> To: Jerin Jacob <jerin.ja...@caviumnetworks.com>, Ferruh Yigit >> <ferruh.yi...@intel.com>, "Ananyev, Konstantin" >> <konstantin.anan...@intel.com> >> Cc: Andrew Rybchenko <arybche...@solarflare.com>, "Lu, Wenzhuo" >> <wenzhuo...@intel.com>, "Wu, Jingjing" <jingjing...@intel.com>, >> "Iremonger, Bernard" <bernard.iremon...@intel.com>, "Mcnamara, John" >> <john.mcnam...@intel.com>, "Kovacevic, Marko" <marko.kovace...@intel.com>, >> Olivier Matz <olivier.m...@6wind.com>, "dev@dpdk.org" <dev@dpdk.org>, >> "shah...@mellanox.com" <shah...@mellanox.com>, "didier.pall...@6wind.com" >> <didier.pall...@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 <ferruh.yi...@intel.com> >>>> On 10/6/2018 1:18 PM, Ananyev, Konstantin wrote: >>>>> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] >>>>>> From: Thomas Monjalon <tho...@monjalon.net> >>>>>>> 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.
