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
