> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, July 15, 2015 4:01 PM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v10 00/19] unified packet type > > 2015-07-10 00:31, Helin Zhang: > > Currently only 6 bits which are stored in ol_flags are used to > > indicate the packet types. This is not enough, as some NIC hardware > > can recognize quite a lot of packet types, e.g i40e hardware can > > recognize more than 150 packet types. Hiding those packet types hides > > hardware offload capabilities which could be quite useful for improving > performance and for end users. > > So an unified packet types are needed to support all possible PMDs. A > > 16 bits packet_type in mbuf structure can be changed to 32 bits and > > used for this purpose. In addition, all packet types stored in ol_flag > > field should be deleted at all, and 6 bits of ol_flags can be save as the > > benifit. > > > > Initially, 32 bits of packet_type can be divided into several sub > > fields to indicate different packet type information of a packet. The > > initial design is to divide those bits into fields for L2 types, L3 > > types, L4 types, tunnel types, inner L2 types, inner L3 types and > > inner L4 types. All PMDs should translate the offloaded packet types > > into these 7 fields of information, for user applications. > > > > To avoid breaking ABI compatibility, currently all the code changes > > for unified packet type are disabled at compile time by default. Users > > can enable it manually by defining the macro of RTE_NEXT_ABI. The code > > changes will be valid by default in a future release, and the old > > version will be deleted accordingly, after the ABI change process is done. > > Applied with fixes for cxgbe and mlx4, thanks everyone > > The macro RTE_ETH_IS_TUNNEL_PKT may need to take RTE_PTYPE_INNER_* > into account.
Thank you so much! Thanks to all the contributors! Helin
