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

[Olivier Matz <olivier.matz@6wind.com>]

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 ;)

> > 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().

Olivier