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: m...@smartsharesystems.com [mailto:m...@smartsharesystems.com] > Sent: Wednesday, January 9, 2019 10:39 PM > To: long...@viettel.com.vn; roszenr...@gmail.com; Olivier Matz > <olivier.m...@6wind.com> > Cc: dev@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-boun...@dpdk.org] On Behalf Of > > long...@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
