[dpdk-dev] [RFC 01/17] mbuf: add definitions of unified packet types

[Neil Horman]

On Mon, Jan 19, 2015 at 06:27:02PM +0100, Olivier MATZ wrote:
> Hi,
> 
> On 01/19/2015 05:33 PM, Neil Horman wrote:
> > On Mon, Jan 19, 2015 at 11:23:07AM +0800, Helin Zhang wrote:
> >> As there are only 6 bit flags in ol_flags for indicating packet types,
> >> which is not enough to describe all the possible packet types hardware
> >> can recognize. For example, i40e hardware can recognize more than 150
> >> packet types. Unified packet type is composed of tunnel type, L3 type,
> >> L4 type and inner L3 type fields, and can be stored in 16 bits mbuf
> >> field of 'packet_type'.
> >>
> >> Signed-off-by: Helin Zhang <helin.zhang at intel.com>
> >> Signed-off-by: Cunming Liang <cunming.liang at intel.com>
> >> Signed-off-by: Jijiang Liu <jijiang.liu at intel.com>
> >> ---
> >>  lib/librte_mbuf/rte_mbuf.h | 68 ++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 68 insertions(+)
> >>
> >> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> >> index 16059c6..94eb38f 100644
> >> --- a/lib/librte_mbuf/rte_mbuf.h
> >> +++ b/lib/librte_mbuf/rte_mbuf.h
> >> @@ -165,6 +165,74 @@ extern "C" {
> >>  /* Use final bit of flags to indicate a control mbuf */
> >>  #define CTRL_MBUF_FLAG       (1ULL << 63) /**< Mbuf contains control data */
> >>  
> >> +/*
> >> + * Sixteen bits are divided into several fields to mark packet types. Note that
> >> + * each field is indexical.
> >> + * - Bit 3:0 is for tunnel types.
> >> + * - Bit 7:4 is for L3 or outer L3 (for tunneling case) types.
> >> + * - Bit 10:8 is for L4 types. It can also be used for inner L4 types for
> >> + *   tunneling packets.
> > This seems a bit sparse, in that the protocol field is 8 bits wide in a packet.
> > There are several common protocls that you don't have listed, and you've already
> > exhausted your namespace with the list you have.
> > Neil
> 
> Another question I've asked several times[1][2] : what does having
> RTE_PTYPE_TUNNEL_IP mean? What fields are checked by the hardware
> (or the driver) and what fields should be checked by the application?
> Are you sure that all the drivers (ixgbe, i40e, vmxnet3, enic) check
> the same fields? (ethertype, ip version, ip len correct, ip checksum
> correct, flags, ...)
> 
> To be clearer: Let's say I have a network stack that parses and
> validates an IP packet. What tests can I remove if I get
> RTE_PTYPE_TUNNEL_IP?
> 
> This question can be asked for all defined packet type. To be usable by
> an application, I think a formal definition would be needed. This is
> also important to know this for people wanting to develop a new PMD
> based on a new hardware. If the hardware does not behave exactly like
> ixgbe, i40e (I hope all drivers you implemented behave exactly the
> same), some work has to be done in the driver or the feature cannot be
> used.
> 
> One naïve question: are we sure that at the end, using these complex
> packet types is faster than parsing the packet?
> 
Thats an excellent question, especially when you start considering that high
layer stack functions will want to isolate themselves from these complex packet
types.

Neil

> Regards,
> Olivier
> 
> 
> [1] http://dpdk.org/ml/archives/dev/2014-November/008534.html
> [2] http://dpdk.org/ml/archives/dev/2014-November/008367.html
>