[dpdk-dev] [PATCH 00/17] unified packet type

[Olivier MATZ]

Hi Helin,

On 02/02/2015 03:44 AM, Zhang, Helin wrote:
>>>> 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.
> Hmm, I think the packet_type may need to be renamed to else, like offload_packet_type.
> It is just for hardware reported packet type information. It is not for all
> information of a packet.
> As different hardware may have different capability, it cannot report the same
> in mbuf among different hardware for the same packet.
> With your question, I think the hardware capability flags may be needed. Applications
> can query the packet type capabilities on each port, then it knows what type of packet
> type information can be reported by the corresponding hardware.
> What do you think? And are they any better ideas from you?

I'm not sure renaming the field would change something here.

The high-level question is: how a software can take advantage of this
information given by the hardware? If the same packet_type does not
have the same meaning depending on the hardware, it's not worth having
this info.

I think the API should describe for each packet type what can be
expected by the application. Here is an example. When a driver sets the
RTE_PTYPE_L3_IPV4 type, it means that:

- the layer 3 is identified as IP by underlying layer (ex: ethertype=IP
  if layer 2 is ethernet)
- the IP version field is 4
- there is no IP options (i.e the size of header is 20)
- the checksum field has been verified by hw, and if wrong, the
  flag PKT_RX_IP_CKSUM_BAD is set

If the hardware is not able to give all this information, there are
2 solutions:
- do the remaining tests in the driver
- or set l3 pkt_type to unknown

All other conditions that are not described in the API should be checked
by the applition if it needs the information (ex: check that IP dest
address is legal, that ip->len is >= 20, ...).


If we are able to describe this for all packet types, it would really
help application to take advantage of these packet types.

Regards,
Olivier