Re: [PATCH 1/4] rte_mbuf:add packet types

[Olivier MATZ <olivier.matz-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

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