+- IPv4 ID. The IPv4 ID fields of the packets, whose DF bit is 0, should
+ be increased by 1.
+
+VxLAN GRO
+---------
+
+The table structure used by VxLAN GRO, which is in charge of processing
+VxLAN packets with an outer IPv4 header and inner TCP/IPv4 packet, is
+similar with that of TCP/IPv4 GRO. Differently, the header fields used
+to define a VxLAN flow include:
+
+- outer source and destination: Ethernet and IP address, UDP port
+
+- VxLAN header (VNI and flag)
+
+- inner source and destination: Ethernet and IP address, TCP port
+
+Header fields deciding if packets are neighbors include:
+
+- outer IPv4 ID. The IPv4 ID fields of the packets, whose DF bit in the
+ outer IPv4 header is 0, should be increased by 1.
+
+- inner TCP sequence number
+
+- inner IPv4 ID. The IPv4 ID fields of the packets, whose DF bit in the
+ inner IPv4 header is 0, should be increased by 1.
+
+.. note::
+ We comply RFC 6864 to process the IPv4 ID field. Specifically,
+ we check IPv4 ID fields for the packets whose DF bit is 0 and
+ ignore IPv4 ID fields for the packets whose DF bit is 1.
+ Additionally, packets which have different value of DF bit can't
+ be merged.
+
+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.