[v6] doc: add GRO limitations in prog_guide

Message ID 1547604822-9920-1-git-send-email-jiayu.hu@intel.com (mailing list archive)
State Accepted, archived
Delegated to: Thomas Monjalon
Headers
Series [v6] doc: add GRO limitations in prog_guide |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Hu, Jiayu Jan. 16, 2019, 2:13 a.m. UTC
  This patch adds GRO limitations in the programmer guide.

Fixes: 2c900d09055e ("doc: add GRO guide")
Cc: stable@dpdk.org

Signed-off-by: Jiayu Hu <jiayu.hu@intel.com>
---
changes in v6:
- add VLAN limitation
changes in v5:
- remove fix commit 9e0b9d2ec0f4
changes in v4:
- update MBUF->l2_len/... requirement
changes in v3:
- add MBUF limitation
changes in v2:
- add fix commits
- add more limitations

 doc/guides/prog_guide/generic_receive_offload_lib.rst | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
  

Comments

Ananyev, Konstantin Jan. 16, 2019, 9:50 a.m. UTC | #1
> -----Original Message-----
> From: Hu, Jiayu
> Sent: Wednesday, January 16, 2019 2:14 AM
> To: dev@dpdk.org
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net; Hu, Jiayu <jiayu.hu@intel.com>; stable@dpdk.org
> Subject: [PATCH v6] doc: add GRO limitations in prog_guide
> 
> This patch adds GRO limitations in the programmer guide.
> 
> Fixes: 2c900d09055e ("doc: add GRO guide")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Jiayu Hu <jiayu.hu@intel.com>
> ---
> changes in v6:
> - add VLAN limitation
> changes in v5:
> - remove fix commit 9e0b9d2ec0f4
> changes in v4:
> - update MBUF->l2_len/... requirement
> changes in v3:
> - add MBUF limitation
> changes in v2:
> - add fix commits
> - add more limitations
> 
>  doc/guides/prog_guide/generic_receive_offload_lib.rst | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/generic_receive_offload_lib.rst b/doc/guides/prog_guide/generic_receive_offload_lib.rst
> index 9c6a4d0..5b3fb91 100644
> --- a/doc/guides/prog_guide/generic_receive_offload_lib.rst
> +++ b/doc/guides/prog_guide/generic_receive_offload_lib.rst
> @@ -191,3 +191,22 @@ Header fields deciding if packets are neighbors include:
>          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.
> --

Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>

> 2.7.4
  
Kovacevic, Marko Jan. 17, 2019, 1:55 p.m. UTC | #2
> +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.
  
Thomas Monjalon Jan. 17, 2019, 10:08 p.m. UTC | #3
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.
  
Thomas Monjalon Jan. 17, 2019, 10:08 p.m. UTC | #4
16/01/2019 10:50, Ananyev, Konstantin:
> From: Hu, Jiayu
> > 
> > This patch adds GRO limitations in the programmer guide.
> > 
> > Fixes: 2c900d09055e ("doc: add GRO guide")
> > Cc: stable@dpdk.org
> > 
> > Signed-off-by: Jiayu Hu <jiayu.hu@intel.com>
> > ---
> > changes in v6:
> > - add VLAN limitation
> > changes in v5:
> > - remove fix commit 9e0b9d2ec0f4
> > changes in v4:
> > - update MBUF->l2_len/... requirement
> > changes in v3:
> > - add MBUF limitation
> > changes in v2:
> > - add fix commits
> > - add more limitations
> 
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>

Applied, thanks
  

Patch

diff --git a/doc/guides/prog_guide/generic_receive_offload_lib.rst b/doc/guides/prog_guide/generic_receive_offload_lib.rst
index 9c6a4d0..5b3fb91 100644
--- a/doc/guides/prog_guide/generic_receive_offload_lib.rst
+++ b/doc/guides/prog_guide/generic_receive_offload_lib.rst
@@ -191,3 +191,22 @@  Header fields deciding if packets are neighbors include:
         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.