From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [RFC] function to parse packet headers
Date: Thu, 10 Jan 2019 00:57:46 +0100
Message-ID: <3446539.r5cUhzCBca@xps>
References: <98CBD80474FA8B44BF855DF32C47DC35B425B1@smartserver.smartshare.dk>
 <CAKoUArmoWha8f=bTcvXWfSBH26KAvxqRqmWSHx4RCA6PatA5RA@mail.gmail.com>
 <98CBD80474FA8B44BF855DF32C47DC35B425B8@smartserver.smartshare.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dev@dpdk.org, Rami Rosen <roszenrami@gmail.com>, olivier.matz@6wind.com,
 arybchenko@solarflare.com, ferruh.yigit@intel.com
To: Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 5527691
 for <dev@dpdk.org>; Thu, 10 Jan 2019 00:57:49 +0100 (CET)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B425B8@smartserver.smartshare.dk>
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>

Adding few more Cc's

09/01/2019 16:53, Morten Br=F8rup:
> From: Rami Rosen [mailto:roszenrami@gmail.com]=20
> >Hi Morten,
> >A good idea, thanks for volunteering!=20
> >Several minor comments:=20
> >I would consider calling it rte_mbuf_hdr_parse(), to make it more relate=
d to the rte_mbuf* methods, and also I would consider having it in librte_m=
buf and not in librte_net as you suggested.
>=20
> I considered this, but since it looks inside the packet data, and not jus=
t processes metadata, I think it doesn't belong in librte_mbuf.
>=20
> >
> >Also regarding the bulk method. The first option is indeed faster and be=
tter in terms of performance, which is important since it is intended proba=
bly mostly to the datapath. I would consider having the bulk method iterati=
ng over the rte_hdr_parse() method ,( or rte_mbuf_hdr_parse() if you will a=
gree to my suggestion), and adding a boolean parameter (mark_malform or som=
ething like that) to this method + removing the const quailifier. The bulk =
method will set that flag when calling the rte_hdr_parse(). Thus you will a=
void duplicity of the parsing code.
>=20
> Good points...
>=20
> And regarding avoiding code duplicity, I'm pursuing Olivier about merging=
 packet header validation into rte_net_get_ptype() instead of writing a sep=
arate function.
>=20
> >
> >Regards,
> >Rami Rosen