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
