From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH 17/17] mbuf: remove old packet type bit masks for ol_flags Date: Mon, 02 Feb 2015 12:22:56 +0100 Message-ID: <54CF5E10.8050408@6wind.com> References: <1421637666-16872-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-18-git-send-email-helin.zhang@intel.com> <54CB890B.406@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: "Zhang, Helin" , "dev-VfR2kkLFssw@public.gmane.org" Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi Helin, On 02/02/2015 02:53 AM, Zhang, Helin wrote: >> */ >>> /* case PKT_RX_RECIP_ERR: return "PKT_RX_RECIP_ERR"; */ >>> /* case PKT_RX_MAC_ERR: return "PKT_RX_MAC_ERR"; */ >>> - case PKT_RX_IPV4_HDR: return "PKT_RX_IPV4_HDR"; >>> - case PKT_RX_IPV4_HDR_EXT: return "PKT_RX_IPV4_HDR_EXT"; >>> - case PKT_RX_IPV6_HDR: return "PKT_RX_IPV6_HDR"; >>> - case PKT_RX_IPV6_HDR_EXT: return "PKT_RX_IPV6_HDR_EXT"; >>> case PKT_RX_IEEE1588_PTP: return "PKT_RX_IEEE1588_PTP"; >>> case PKT_RX_IEEE1588_TMST: return "PKT_RX_IEEE1588_TMST"; >>> - case PKT_RX_TUNNEL_IPV4_HDR: return "PKT_RX_TUNNEL_IPV4_HDR"; >>> - case PKT_RX_TUNNEL_IPV6_HDR: return "PKT_RX_TUNNEL_IPV6_HDR"; >> >> I see you are not removing IEEE1588. Is there a reason why it is not handled as >> a packet_type? > Ieee1588 is not a part of information reported by hardware in packet type. > Yes, your idea on this is worth being taken into account. This would indeed be more coherent. In this case, I think it would require to add a l2_type in the packet_type info. >>> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h >>> index 94ae344..5df0d61 100644 >>> --- a/lib/librte_mbuf/rte_mbuf.h >>> +++ b/lib/librte_mbuf/rte_mbuf.h >>> @@ -90,16 +90,10 @@ extern "C" { >>> #define PKT_RX_HBUF_OVERFLOW (0ULL << 0) /**< Header buffer >> overflow. */ >>> #define PKT_RX_RECIP_ERR (0ULL << 0) /**< Hardware processing >> error. */ >>> #define PKT_RX_MAC_ERR (0ULL << 0) /**< MAC error. */ >>> -#define PKT_RX_IPV4_HDR (1ULL << 5) /**< RX packet with IPv4 >> header. */ >>> -#define PKT_RX_IPV4_HDR_EXT (1ULL << 6) /**< RX packet with >> extended IPv4 header. */ >>> -#define PKT_RX_IPV6_HDR (1ULL << 7) /**< RX packet with IPv6 >> header. */ >>> -#define PKT_RX_IPV6_HDR_EXT (1ULL << 8) /**< RX packet with >>> extended IPv6 header. */ #define PKT_RX_IEEE1588_PTP (1ULL << 9) >>> /**< RX IEEE1588 L2 Ethernet PT Packet. */ #define >>> PKT_RX_IEEE1588_TMST (1ULL << 10) /**< RX IEEE1588 L2/L4 timestamped >>> packet.*/ -#define PKT_RX_TUNNEL_IPV4_HDR (1ULL << 11) /**< RX tunnel >> packet with IPv4 header.*/ -#define PKT_RX_TUNNEL_IPV6_HDR (1ULL << 12) >> /**< RX tunnel packet with IPv6 header. */ >>> -#define PKT_RX_FDIR_ID (1ULL << 13) /**< FD id reported if FDIR >> match. */ >>> -#define PKT_RX_FDIR_FLX (1ULL << 14) /**< Flexible bytes reported if >> FDIR match. */ >>> +#define PKT_RX_FDIR_ID (1ULL << 11) /**< FD id reported if FDIR >> match. */ >>> +#define PKT_RX_FDIR_FLX (1ULL << 12) /**< Flexible bytes reported if >> FDIR match. */ >> >> It looks like but numbers are not contiguous anymore (there is a hole between >> 5 and 8). > Initially I don't want to move the following values up, as I am not sure if it may > affect other features. > I'd prefer to keep that hole as reserved. What's the opinion from you guys? > Thanks for the good comments! I think changing the flags bit value to keep ordering is not a problem. Regards, Olivier