From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id DA9815A85 for ; Fri, 30 Jan 2015 14:31:19 +0100 (CET) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YHBis-0007RZ-JL; Fri, 30 Jan 2015 14:35:02 +0100 Message-ID: <54CB879D.2010505@6wind.com> Date: Fri, 30 Jan 2015 14:31:09 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Helin Zhang , dev@dpdk.org References: <1421637666-16872-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-1-git-send-email-helin.zhang@intel.com> In-Reply-To: <1422501365-12643-1-git-send-email-helin.zhang@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 00/17] unified packet type X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 13:31:20 -0000 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