From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by dpdk.org (Postfix) with ESMTP id CB0455A70 for ; Tue, 20 Jan 2015 10:53:30 +0100 (CET) Received: by mail-we0-f182.google.com with SMTP id l61so10767075wev.13 for ; Tue, 20 Jan 2015 01:53:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QCVJaCUbwxRZcKfWHJpwWdrp6RtD3UjirimBDNi09jQ=; b=joLLgsB+ZMTG4FyWz05GYs6msPL7Q4a6VI1fRNYgdekuz80pm57QmcvduZwlOBTcMz LZqUN2eGz+bicj/5Gv/v+trScc4CPr04bn8DUeCDWAKPDUCqX3XexQX4OLRehDKQhPxv p66ef+wIzey042hKJ05aODzSLBVR6m0sJqva0kqdwXCjvVDDzZVKRKlRwT6y3o50+Jyq uj4Dc3NvxjK7ia3qZvObSjmbOJWqhPeHhZV2Ogb0+ijrP+LpOtbuFGCzlJdIAS9Oi0NG yHJ/dZIL8YB/HixBEx+gly2Z47d+NSbgv+t9n0as3F/Ir84CrxiH/XrCVHNb8Yt5vVVt 0qDQ== X-Gm-Message-State: ALoCoQkwtbl1rgmL4V65BhIrvXn/kC/TR+tTJ/JFyOUsA2OE5MXEIgBYjaZizAGORKnoTPoxKGTd X-Received: by 10.180.228.72 with SMTP id sg8mr45123440wic.48.1421747610492; Tue, 20 Jan 2015 01:53:30 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id vs8sm20575813wjc.6.2015.01.20.01.53.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 01:53:29 -0800 (PST) Message-ID: <54BE2598.50608@6wind.com> Date: Tue, 20 Jan 2015 10:53:28 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: "Zhang, Helin" , Neil Horman 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> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [RFC 01/17] mbuf: add definitions of unified packet types 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: Tue, 20 Jan 2015 09:53:31 -0000 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