On 10/8/2018 10:37 AM, Jerin Jacob wrote: > -----Original Message----- >> Date: Mon, 08 Oct 2018 11:04:51 +0200 >> From: Thomas Monjalon <[email protected]> >> To: Jerin Jacob <[email protected]>, Ferruh Yigit >> <[email protected]>, "Ananyev, Konstantin" >> <[email protected]> >> Cc: Andrew Rybchenko <[email protected]>, "Lu, Wenzhuo" >> <[email protected]>, "Wu, Jingjing" <[email protected]>, >> "Iremonger, Bernard" <[email protected]>, "Mcnamara, John" >> <[email protected]>, "Kovacevic, Marko" <[email protected]>, >> Olivier Matz <[email protected]>, "[email protected]" <[email protected]>, >> "[email protected]" <[email protected]>, "[email protected]" >> <[email protected]> >> 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 <[email protected]> >>>> On 10/6/2018 1:18 PM, Ananyev, Konstantin wrote: >>>>> From: Jerin Jacob [mailto:[email protected]] >>>>>> From: Thomas Monjalon <[email protected]> >>>>>>> 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.
