From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [RFC] function to parse packet headers
Date: Thu, 10 Jan 2019 16:11:58 -0800
Message-ID: <20190110161158.0177a203@hermes.lan>
References: <98CBD80474FA8B44BF855DF32C47DC35B425B1@smartserver.smartshare.dk>
 <CAKoUArmoWha8f=bTcvXWfSBH26KAvxqRqmWSHx4RCA6PatA5RA@mail.gmail.com>
 <98CBD80474FA8B44BF855DF32C47DC35B425B8@smartserver.smartshare.dk>
 <3446539.r5cUhzCBca@xps>
 <CAKoUAr=xAnUY4xjDD2wv5dEmonEHHknK_rbO3DJeiMdCKiSfgQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Thomas Monjalon <thomas@monjalon.net>, Morten =?UTF-8?B?QnLDuHJ1cA==?=
 <mb@smartsharesystems.com>, dev@dpdk.org, olivier.matz@6wind.com,
 arybchenko@solarflare.com, ferruh.yigit@intel.com
To: Rami Rosen <roszenrami@gmail.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com
 [209.85.210.172]) by dpdk.org (Postfix) with ESMTP id 467891B96B
 for <dev@dpdk.org>; Fri, 11 Jan 2019 01:12:06 +0100 (CET)
Received: by mail-pf1-f172.google.com with SMTP id q1so6068516pfi.5
 for <dev@dpdk.org>; Thu, 10 Jan 2019 16:12:06 -0800 (PST)
In-Reply-To: <CAKoUAr=xAnUY4xjDD2wv5dEmonEHHknK_rbO3DJeiMdCKiSfgQ@mail.gmail.com>
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>

On Thu, 10 Jan 2019 03:03:24 +0200
Rami Rosen <roszenrami@gmail.com> wrote:

> Hi, Morten,
> 
> > And regarding avoiding code duplicity, I'm pursuing Olivier about merging  
> packet header validation into rte_net_get_ptype() instead of writing a
> separate function.
> >  
> This seems also a good alternative.
> +1
> 
> Regards,
> Rami Rosen
> 

+1
All drivers that don't have hardware support for getting l2/l3 and ptype
information should be calling rte_net_get_ptype() already.