From mboxrd@z Thu Jan  1 00:00:00 1970
From: longtb5@viettel.com.vn
Subject: Re: [RFC] function to parse packet headers
Date: Thu, 10 Jan 2019 10:25:40 +0700 (ICT)
Message-ID: <000001d4a895$85ffbbf0$91ff33d0$@viettel.com.vn>
References: <002301d4a7ce$d095b240$71c116c0$@viettel.com.vn>
 <98CBD80474FA8B44BF855DF32C47DC35B425B7@smartserver.smartshare.dk>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Cc: <dev@dpdk.org>
To: <mb@smartsharesystems.com>, <roszenrami@gmail.com>,
 "'Olivier Matz'" <olivier.matz@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mailfilter01.viettel.com.vn (mailfilter01.viettel.com.vn
 [125.235.240.53]) by dpdk.org (Postfix) with ESMTP id E62201B59C
 for <dev@dpdk.org>; Thu, 10 Jan 2019 04:25:51 +0100 (CET)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B425B7@smartserver.smartshare.dk>
Content-Language: en-us
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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@smartsharesystems.com [mailto:mb@smartsharesystems.com]
> Sent: Wednesday, January 9, 2019 10:39 PM
> To: longtb5@viettel.com.vn; roszenrami@gmail.com; Olivier Matz
> <olivier.matz@6wind.com>
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [RFC] function to parse packet headers
>=20
> Cutting in Olivier, requesting input as the maintainer of rte_net.
>=20
> > 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.
>=20
> 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.)
>=20
> It might be better to extend rte_net_get_ptype() by adding checks for
> malformed packets, rather than introducing an almost similar function.
>=20
> And then the bulk function could use rte_net_get_ptype().
>=20
> >
> > Regards,
> > BL