Re: [dpdk-dev] [PATCH v5] doc: add GRO API limitations in prog_guide

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

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, January 9, 2019 6:20 PM
> To: Hu, Jiayu <jiayu.hu@intel.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>; mb@smartsharesystems.com; thomas@monjalon.net;
> Varghese, Vipin <vipin.varghese@intel.com>; stable@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.