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.
