From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH 1/4] rte_mbuf:add packet types Date: Fri, 21 Nov 2014 14:25:38 +0100 Message-ID: <546F3D52.3070300@6wind.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: "Liu, Jijiang" , "dev-VfR2kkLFssw@public.gmane.org" Return-path: In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9D8D6-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@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" 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