From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [RFC 01/17] mbuf: add definitions of unified packet types Date: Tue, 20 Jan 2015 10:53:28 +0100 Message-ID: <54BE2598.50608@6wind.com> References: <1421637803-17034-1-git-send-email-helin.zhang@intel.com> <1421637803-17034-2-git-send-email-helin.zhang@intel.com> <20150119163306.GD21790@hmsreliant.think-freely.org> <54BD3E66.3040709@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev-VfR2kkLFssw@public.gmane.org" To: "Zhang, Helin" , Neil Horman Return-path: In-Reply-To: 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/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