[dpdk-dev] [PATCH v10 00/19] unified packet type

Zhang, Helin helin.zhang at intel.com
Thu Jul 16 01:51:26 CEST 2015



> -----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


More information about the dev mailing list