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

Olivier MATZ olivier.matz at 6wind.com
Tue Jan 20 10:53:28 CET 2015


Hi Helin,

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.

Regards,
Olivier



More information about the dev mailing list