From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 5527691 for ; Thu, 10 Jan 2019 00:57:49 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EE171223A3; Wed, 9 Jan 2019 18:57:48 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 09 Jan 2019 18:57:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=igNXX8T1OmFufyqQ6QbGDyUho3rbJ2wJlYjUkqQz2i0=; b=gXIhsrrAwviz 4SabO7Jeo5X9GK1wNEIHz7mHfXI8M0Q6WM3S8GNfxxU/MfM4nyBHJugamlmZ8j26 zRpFwyvR6XYEGk8TbJnYYe2AkzltpSuI1SfMajnb/It2rAAQNAngkbAc4wwdrJbP GKN5brgCB3dRIFB1pGdET0fGsE7rVEc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=igNXX8T1OmFufyqQ6QbGDyUho3rbJ2wJlYjUkqQz2 i0=; b=DB6BqbdMlnHnblCCPaSOv/myh3IOh3Vp9AnKgtF5NHi5HZNiHYb/Qd6OM bmFp+hT5tmr934A41wlkJVcE2ZDcMZ8OFY2CIxjxGfRgmzAkplqbPwYN5Eapf7Wl Xc2gCn6utNQCXYuWwL30h4WcdJHMlt0DAYNqN19leCev4naVqoUR+s2/OpcXKWww jmFADnSxPrePdkNyVQwbh/s/UsNZuk0252WrwpfH5DIHtEB7fqF3S5BIjVnBYq6Z XzNNVM/TfifCHIoMcvNjg+M806U0GtXz5iHrNVl+Vzb325hrNq2ghzqy48eIbCNf 1nzy1l2aZS0BfeuuKg3LYCdRuJEbw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedvgddugeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 52736100B8; Wed, 9 Jan 2019 18:57:47 -0500 (EST) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org, Rami Rosen , olivier.matz@6wind.com, arybchenko@solarflare.com, ferruh.yigit@intel.com Date: Thu, 10 Jan 2019 00:57:46 +0100 Message-ID: <3446539.r5cUhzCBca@xps> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B425B8@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35B425B1@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35B425B8@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [RFC] function to parse packet headers X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 23:57:49 -0000 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