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

Olivier MATZ olivier.matz at 6wind.com
Fri Jan 30 14:31:09 CET 2015


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.

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




More information about the dev mailing list