17/01/2019 14:55, Kovacevic, Marko: > > +GRO Library Limitations > > +----------------------- > > + > > +- GRO library uses MBUF->l2_len/l3_len/l4_len/outer_l2_len/ > > + outer_l3_len/packet_type 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/ > > + packet_type to the same values as the protocol headers of the > > + packet. > > + > > +- GRO library doesn't support to process the packets with IPv4 > > + Options or VLAN tagged. > > + > > +- GRO library just supports to process the packet organized > > + in a single MBUF. If the input packet consists of multiple > > + MBUFs (i.e. chained MBUFs), GRO reassembly behaviors are > > + unknown. > > -- > > Would it be better said like this ?? > > - GRO library uses different MBUF->packet_types for example > ``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 calling GRO APIs to merge packets, user applications > must set MBUF->packet_type to the same values as the protocol headers of > the packet.
packet_type is really a field in mbuf. I think the wording from Jiayu is more correct.
