> -----Original Message-----
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Wednesday, January 9, 2019 6:20 PM
> To: Hu, Jiayu <jiayu...@intel.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.anan...@intel.com>;
> m...@smartsharesystems.com; tho...@monjalon.net;
> Varghese, Vipin <vipin.vargh...@intel.com>; sta...@dpdk.org
> Subject: Re: [PATCH v5] doc: add GRO API limitations in prog_guide
>
> O be merged.
> > +
> > +GRO Library Limitations
> > +-----------------------
> > +
> > +- GRO library uses the values of MBUF->l2_len/l3_len/l4_len/
> > + outer_l2_len/outer_l3_len to get protocol headers for the
> > + input packet, rather than parsing the packet header. Therefore,
> > + before call GRO APIs to merge packets, user applications
> > + must set MBUF->l2_len/l3_len/l4_len/outer_l2_len/outer_l3_len
> > + to the same values as the protocol headers of the packet.
> > +
>
> Since these length values are critical to other functionality
> why not require all poll mode drivers to set them.
Most of current HW doesn't provide that functionality,
so RX function would need to parse (touch) packet data.
>From other side not every rx_burst() consumer does use GRO library.
>
> Many poll mode drivers call rte_net_get_ptype() on the received
> mbuf and it already handles setting this.
>
> One could argue that GRO should just log and die if it
> gets malformed data.
