From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH 00/17] unified packet type Date: Fri, 30 Jan 2015 14:31:09 +0100 Message-ID: <54CB879D.2010505@6wind.com> References: <1421637666-16872-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-1-git-send-email-helin.zhang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: Helin Zhang , dev-VfR2kkLFssw@public.gmane.org Return-path: In-Reply-To: <1422501365-12643-1-git-send-email-helin.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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