> -----Original Message-----
> From: Stephen Hemminger [mailto:[email protected]]
> Sent: Wednesday, January 9, 2019 6:20 PM
> To: Hu, Jiayu <[email protected]>
> Cc: [email protected]; Ananyev, Konstantin <[email protected]>;
> [email protected]; [email protected];
> Varghese, Vipin <[email protected]>; [email protected]
> 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.
