Re: [dpdk-dev] [RFC] function to parse packet headers

["Morten Brørup" <mb@smartsharesystems.com>]

Cutting in Olivier, requesting input as the maintainer of rte_net.

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of
> longtb5@viettel.com.vn
> 
> Hi Morten,
> 
> What is the difference compare to rte_net_get_ptype(), which also
> parses
> packet types and reports on header length.
> 
> In my application I have also done something similar about malformed
> packets. IMO it's very useful to have return value indicate different
> types
> of malformed packets, not just -1, e.g. invalid IP options, IP
> loopback,
> etc.

They are very similar. The main differences are:
- The header length fields are set in the MBUF, not returned in a separate structure. This would only be relevant for a bulk function.
- In theory, it would be possible to set the length fields without accessing the packet data, but just by looking at MBUF->packet_type for some packets; e.g. RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP is quite common due to Google's QUIC protocol (and will be with the coming HTTP/3 protocol).
- Testing for malformed packets, e.g. a length field suggesting that the packet is longer than it actually is, or a header length field suggesting that the header is shorter than the header's structure. (This obviously requires accessing the packet data, which makes the above point about not accessing the packet data irrelevant.)

It might be better to extend rte_net_get_ptype() by adding checks for malformed packets, rather than introducing an almost similar function.

And then the bulk function could use rte_net_get_ptype().

> 
> Regards,
> BL