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 <roszenr...@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
