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

[longtb5 at viettel.com.vn]

Also for the bulk API, another option would be passing in a `uint64_t malformed_mask` and let the bulk function set the correspond bit (1 << pos) of that mask if the packet at position pos is malformed.

void rte_hdr_parse_bulk(struct rte_mbuf **pkts, uint64_t *malformed_mask, uint_fast16_t nb_pkts);

The packet mask idea is used extensively in the packet framework (rte_pipeline, rte_port, rte_table).

> -----Original Message-----
> From: mb at smartsharesystems.com [mailto:mb at smartsharesystems.com]
> Sent: Wednesday, January 9, 2019 10:39 PM
> To: longtb5 at viettel.com.vn; roszenrami at gmail.com; Olivier Matz
> <olivier.matz at 6wind.com>
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [RFC] function to parse packet headers
> 
> Cutting in Olivier, requesting input as the maintainer of rte_net.
> 
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of
> > longtb5 at 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