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 >