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 8B8937F74 for ; Fri, 21 Nov 2014 14:15:15 +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.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XroGb-0005b2-SC; Fri, 21 Nov 2014 14:28:57 +0100 Message-ID: <546F3D52.3070300@6wind.com> Date: Fri, 21 Nov 2014 14:25:38 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Liu, Jijiang" , "dev@dpdk.org" References: <1416296251-7534-1-git-send-email-jijiang.liu@intel.com> <1416296251-7534-2-git-send-email-jijiang.liu@intel.com> <546C733C.1020404@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9D8D6@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9D8D6@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/4] rte_mbuf:add 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: Fri, 21 Nov 2014 13:15:15 -0000 Hello Jijiang, On 11/21/2014 01:26 PM, Liu, Jijiang wrote: >> I have one question about the packet_type: it is not clear to me what the >> software can expect, for instance when RTE_PTYPE_IPv4_IPv4 is set. What does >> that mean exactly? Which fields must be valid in the packet to have this type? >> - L2 ethertype >> - Presence of vlan? >> - IP version >> - IP checksum >> - IP header length >> - IP length (compared to packet len) >> - anything about IP options? > The RTE_PTYPE_IPv4_IPv4 means that packet format is MAC, IPV4, IPV4, PAY3. The following fields are valid, > L2 ethertype > No VLAN > IPv4, OK. But IPv4 is not a field, it's a header composed of several fields. When a network stack receives a packet, it checks the validity of the IPv4 fields. The offload flags helps the application to avoid doing some checks, that's why it's important to know what the hardware already verified when a flag is set. Here is a example of what the application may check. Knowing the meaning of the flag is having an answer to these questions. I probably forgot some, but I think you get the point. When RTE_PTYPE_IPv4 is set does it mean that IP.version is 4? When RTE_PTYPE_IPv4 is set does it mean that IP.ihl is not smaller than 5? When RTE_PTYPE_IPv4 is set does it mean that IP.ihl is not higher than 15? When RTE_PTYPE_IPv4 is set does it mean that IP.checksum is verified? When RTE_PTYPE_IPv4 is set does it mean that IP.total_len is not lower than 20? When RTE_PTYPE_IPv4 is set does it mean that IP.total_len is not higher than m_len(m) + 14? When RTE_PTYPE_IPv4 is set does it mean that IP.total_len is not lower than m_len(m) + 14? (there is a trap here) When RTE_PTYPE_IPv4 is set does it mean that (IP.flags & 1) is 0? When RTE_PTYPE_IPv4 is set does it mean that IP.offset is lower than 65528? When RTE_PTYPE_IPv4 is set, can the packet be a fragment? When RTE_PTYPE_IPv4 is set does it mean that there is no options? Any condition on source/dest address? The same questions (but adapted to the protocol) could be asked for any packet type, that was just an example. >> - remove similar things in ol_flags to avoid having a redundant API. > > Yes, when all i40e/ixgbe/igb PMDs done, the related IP header offload should be removed. > I just changed for i40e, there still are igb&ixgbe need to be changed in DPDK2.0, so we can't remove the IP ol_flags now. How can an application deal with 2 different APIs ? The application should work with any driver. It can have a i40e interface and an ixgbe interface at the same time. Regards, Olivier