Re: [dpdk-dev] [RFC] function to parse packet headers

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> Sent: Friday, January 11, 2019 8:36 AM
> To: Andrew Rybchenko <arybchenko@solarflare.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>; Rami Rosen <roszenrami@gmail.com>; Thomas Monjalon
> <thomas@monjalon.net>; Morten Brørup <mb@smartsharesystems.com>; dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>
> Subject: Re: [dpdk-dev] [RFC] function to parse packet headers
> 
> Hi,
> 
> On Fri, Jan 11, 2019 at 10:56:11AM +0300, Andrew Rybchenko wrote:
> > On 1/11/19 3:11 AM, Stephen Hemminger wrote:
> > > 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
> 
> Thanks Morten for volunteering for this task. I also think that rte_net
> is the proper place. rte_net_get_ptype() is indeed quite similar, except
> that it won't return any length. So it may not be that easy to share the
> code between rte_net_get_ptype().
> 
> As an aside, the Rx and Tx offloads fields are distinct. In Rx we have the
> packet type that does not contain the length information, while in Tx we only
> have the lengths. I'm sure there will be some benefits to merge them, but it's
> another topic.
> 
> About the function name, I feel "parse()" is a bit vague. What about something
> like rte_net_set_tx_offload(), rte_net_set_offload_lengths() or
> rte_net_set_tx_ol_len()?
> 
> For the bulk API, marking invalid packets seems good, but I can't find a
> good place for the mark.
> Maybe setting m->tx_offload to INVALID (0xffffffff), or adding a specific
> flag. Any better idea is welcome ;)

We probably can reset ptype to UKNOWN in that case,
but my prefrence would be just group inavlid/unknown packets in some way
(put them beyond good ones, move into different array, etc.)

> 
> > > All drivers that don't have hardware support for getting l2/l3 and ptype
> > > information should be calling rte_net_get_ptype() already.
> >
> > Is it documented somewhere?
> 
> I don't think it's mandatory. Each driver can announce its supported ptype
> through rte_eth_dev_get_supported_ptypes().

+ 1
It shouldn't be mandatory for PMD to do that.
Konstantin