Correct several documentation issues: - Change "is in charge of process" to "is in charge of processing" - Change "which process N packets" to "which processes N packets" - Change "existed packets" to "existing packets" - Change "require our algorithm is" to "require that our algorithm is" - Change "If find" to "If it finds" and "If can't find" to "If it cannot find" - Change "can't merge" to "cannot merge" - Change "doesn't support to process" to "doesn't support processing" - Change "just supports to process the packet" to "only supports processing packets" - Change "before call GRO APIs" to "before calling GRO APIs"
Signed-off-by: Stephen Hemminger <[email protected]> --- .../generic_receive_offload_lib.rst | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/guides/prog_guide/generic_receive_offload_lib.rst b/doc/guides/prog_guide/generic_receive_offload_lib.rst index f2b5ff9eed..66e07d47f4 100644 --- a/doc/guides/prog_guide/generic_receive_offload_lib.rst +++ b/doc/guides/prog_guide/generic_receive_offload_lib.rst @@ -17,7 +17,7 @@ Overview -------- In the GRO library, there are many GRO types which are defined by packet -types. One GRO type is in charge of process one kind of packets. For +types. One GRO type is in charge of processing one kind of packets. For example, TCP/IPv4 GRO processes TCP/IPv4 packets. Each GRO type has a reassembly function, which defines own algorithm and @@ -47,7 +47,7 @@ Lightweight Mode API ~~~~~~~~~~~~~~~~~~~~ The lightweight mode only has one function ``rte_gro_reassemble_burst()``, -which process N packets at a time. Using the lightweight mode API to +which processes N packets at a time. Using the lightweight mode API to merge packets is very simple. Calling ``rte_gro_reassemble_burst()`` is enough. The GROed packets are returned to applications as soon as it finishes. @@ -69,7 +69,7 @@ Secondly, applications use ``rte_gro_reassemble()`` to merge packets. If input packets have invalid parameters, ``rte_gro_reassemble()`` returns them to applications. For example, packets of unsupported GRO types or TCP SYN packets are returned. Otherwise, the input packets are -either merged with the existed packets in the tables or inserted into the +either merged with the existing packets in the tables or inserted into the tables. Finally, applications use ``rte_gro_timeout_flush()`` to flush packets from the tables, when they want to get the GROed packets. @@ -98,7 +98,7 @@ challenges in the algorithm design: - packet reordering makes it hard to merge packets. For example, Linux GRO fails to merge packets when encounters packet reordering. -The above two challenges require our algorithm is: +The above two challenges require that our algorithm is: - lightweight enough to scale fast networking speed @@ -114,13 +114,13 @@ key-based algorithm. Packets are classified into "flows" by some header fields (we call them as "key"). To process an input packet, the algorithm searches for a matched "flow" (i.e., the same value of key) for the packet first, then checks all packets in the "flow" and tries to find a -"neighbor" for it. If find a "neighbor", merge the two packets together. -If can't find a "neighbor", store the packet into its "flow". If can't +"neighbor" for it. If it finds a "neighbor", merge the two packets together. +If it cannot find a "neighbor", store the packet into its "flow". If it cannot find a matched "flow", insert a new "flow" and store the packet into the "flow". .. note:: - Packets in the same "flow" that can't merge are always caused + Packets in the same "flow" that cannot merge are always caused by packet reordering. The key-based algorithm has two characters: @@ -199,15 +199,15 @@ 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 + before calling 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 +- GRO library doesn't support processing packets with IPv4 Options or VLAN tagged. -- GRO library just supports to process the packet organized +- GRO library only supports processing packets organized in a single MBUF. If the input packet consists of multiple MBUFs (i.e. chained MBUFs), GRO reassembly behaviors are unknown. -- 2.51.0
