Re: [dpdk-dev] [PATCH 00/17] unified packet type

["Zhang, Helin" <helin.zhang@intel.com>]

Hi Olivier

> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Friday, January 30, 2015 9:31 PM
> To: Zhang, Helin; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 00/17] unified packet type
> 
> Hi Helin,
> 
> On 01/29/2015 04:15 AM, Helin Zhang wrote:
> > 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.
> > Recently a 16 bits packet_type field has been added in mbuf header
> > which can be 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, 16 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 4 fields for L3 types,
> > tunnel types, inner L3 types and L4 types. All PMDs should translate
> > the offloaded packet types into this 4 fields of information, for user
> applications.
> 
> You haven't answered to my question I asked in your RFC patch [1].
> I copied it below:
> 
> 
> >> On 01/20/2015 03:28 AM, Zhang, Helin wrote:
> >>>> 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, ...)
> >>> RTE_PTYPE_TUNNEL_IP means hardware recognizes the received packet
> as
> >>> an IP-in-IP packet.
> >>> All the fields are filled by PMD which is recognized by hardware.
> >>> The application can just use it which can save some cpu cycles to
> >>> recognize the packet type by software.
> >>> Drivers is responsible for filling with correct values according to
> >>> the packet types recognized by its hardware. Different PMDs may fill
> >>> with different values based on different capabilities.
> >>
> >> Sorry, that does not answer to my question.
> >>
> >> Let's take a simple example. Imagine a hardware-1 that is able to
> >> recognize an IP packet by checking the ethertype and that the IP
> >> version is set to 4.
> >> Another hardware-2 recognize an IP packet by checking the ethertype,
> >> the IP version and that the IP length is correct compared to m_len(m).
> >>
> >> For the same packet, both hardwares will return RTE_PTYPE_L3_IPV4,
> >> but they don't do the same checks on the packet. As I want my
> >> application behave exactly the same whatever the hardware, I need to
> >> know what checks are done in hardware, so I can decide what checks
> >> must be done in my application.
> >>
> >> Example of definition: RTE_PTYPE_L3_IPV4 means that ethertype is
> >> 0x0800 and IP.version is 4.
> >>
> >> It means that I can skip these 2 tests in my application if I have
> >> this packet_type, but all other checks must be done in software (ip
> >> length, flags, checksum, ...)
> >>
> >> For each packet type, we need a definition like above, and we must
> >> check that all drivers setting a packet type behave like described.
Hmm, I think the packet_type may need to be renamed to else, like offload_packet_type.
It is just for hardware reported packet type information. It is not for all
information of a packet.
As different hardware may have different capability, it cannot report the same
in mbuf among different hardware for the same packet.
With your question, I think the hardware capability flags may be needed. Applications
can query the packet type capabilities on each port, then it knows what type of packet
type information can be reported by the corresponding hardware.
What do you think? And are they any better ideas from you?

Thanks you very much!

Regards,
Helin

> 
> I'm not opposed to have a packet_type field in rx mbuf, but I really think the
> question above is an important question to make this feature useful to the
> applications.
> 
> 
> Regards,
> Olivier
> 
> [1] http://dpdk.org/ml/archives/dev/2015-January/011273.html
>