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

[Ananyev, Konstantin]

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