d/numam-dpdk
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
e62c5a12d9
numam-dpdk/lib/librte_gro/rte_gro.c

449 lines
13 KiB
C
Raw Normal View History

lib: use SPDX tag for Intel copyright files Replace the BSD license header with the SPDX tag for files with only an Intel copyright on them. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
2017-12-19 15:49:03 +00:00
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2017 Intel Corporation
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
*/
#include <rte_malloc.h>
#include <rte_mbuf.h>
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
#include <rte_cycles.h>
#include <rte_ethdev.h>
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
#include "rte_gro.h"
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
#include "gro_tcp4.h"
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
#include "gro_udp4.h"
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
#include "gro_vxlan_tcp4.h"
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
#include "gro_vxlan_udp4.h"
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
typedef void *(*gro_tbl_create_fn)(uint16_t socket_id,
uint16_t max_flow_num,
uint16_t max_item_per_flow);
typedef void (*gro_tbl_destroy_fn)(void *tbl);
typedef uint32_t (*gro_tbl_pkt_count_fn)(void *tbl);
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
static gro_tbl_create_fn tbl_create_fn[RTE_GRO_TYPE_MAX_NUM] = {
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
gro_tcp4_tbl_create, gro_vxlan_tcp4_tbl_create,
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
gro_udp4_tbl_create, gro_vxlan_udp4_tbl_create, NULL};
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
static gro_tbl_destroy_fn tbl_destroy_fn[RTE_GRO_TYPE_MAX_NUM] = {
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
gro_tcp4_tbl_destroy, gro_vxlan_tcp4_tbl_destroy,
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
gro_udp4_tbl_destroy, gro_vxlan_udp4_tbl_destroy,
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
NULL};
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
static gro_tbl_pkt_count_fn tbl_pkt_count_fn[RTE_GRO_TYPE_MAX_NUM] = {
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
gro_tcp4_tbl_pkt_count, gro_vxlan_tcp4_tbl_pkt_count,
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
gro_udp4_tbl_pkt_count, gro_vxlan_udp4_tbl_pkt_count,
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
NULL};
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
#define IS_IPV4_TCP_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \
((ptype & RTE_PTYPE_L4_TCP) == RTE_PTYPE_L4_TCP))
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
#define IS_IPV4_UDP_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \
((ptype & RTE_PTYPE_L4_UDP) == RTE_PTYPE_L4_UDP))
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
#define IS_IPV4_VXLAN_TCP4_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \
((ptype & RTE_PTYPE_L4_UDP) == RTE_PTYPE_L4_UDP) && \
((ptype & RTE_PTYPE_TUNNEL_VXLAN) == \
RTE_PTYPE_TUNNEL_VXLAN) && \
((ptype & RTE_PTYPE_INNER_L4_TCP) == \
RTE_PTYPE_INNER_L4_TCP) && \
(((ptype & RTE_PTYPE_INNER_L3_MASK) & \
(RTE_PTYPE_INNER_L3_IPV4 | \
RTE_PTYPE_INNER_L3_IPV4_EXT | \
RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN)) != 0))
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
#define IS_IPV4_VXLAN_UDP4_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \
((ptype & RTE_PTYPE_L4_UDP) == RTE_PTYPE_L4_UDP) && \
((ptype & RTE_PTYPE_TUNNEL_VXLAN) == \
RTE_PTYPE_TUNNEL_VXLAN) && \
((ptype & RTE_PTYPE_INNER_L4_UDP) == \
RTE_PTYPE_INNER_L4_UDP) && \
(((ptype & RTE_PTYPE_INNER_L3_MASK) & \
(RTE_PTYPE_INNER_L3_IPV4 | \
RTE_PTYPE_INNER_L3_IPV4_EXT | \
RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN)) != 0))
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
/*
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
* GRO context structure. It keeps the table structures, which are
* used to merge packets, for different GRO types. Before using
* rte_gro_reassemble(), applications need to create the GRO context
* first.
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
*/
struct gro_ctx {
/* GRO types to perform */
uint64_t gro_types;
/* reassembly tables */
void *tbls[RTE_GRO_TYPE_MAX_NUM];
};
void *
rte_gro_ctx_create(const struct rte_gro_param *param)
{
struct gro_ctx *gro_ctx;
gro_tbl_create_fn create_tbl_fn;
uint64_t gro_type_flag = 0;
uint64_t gro_types = 0;
uint8_t i;
gro_ctx = rte_zmalloc_socket(__func__,
sizeof(struct gro_ctx),
RTE_CACHE_LINE_SIZE,
param->socket_id);
if (gro_ctx == NULL)
return NULL;
for (i = 0; i < RTE_GRO_TYPE_MAX_NUM; i++) {
gro: fix bitwise overflow When try to get GRO types, expression "1 << i" with type "int" may overflow. This patch is to fix this issue. Coverity issue: 158664 Fixes: e996506a1c07 ("lib/gro: add Generic Receive Offload API framework") Signed-off-by: Jiayu Hu <jiayu.hu@intel.com>
2017-07-31 01:43:24 +00:00
gro_type_flag = 1ULL << i;
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
if ((param->gro_types & gro_type_flag) == 0)
continue;
create_tbl_fn = tbl_create_fn[i];
if (create_tbl_fn == NULL)
continue;
gro_ctx->tbls[i] = create_tbl_fn(param->socket_id,
param->max_flow_num,
param->max_item_per_flow);
if (gro_ctx->tbls[i] == NULL) {
/* destroy all created tables */
gro_ctx->gro_types = gro_types;
rte_gro_ctx_destroy(gro_ctx);
return NULL;
}
gro_types |= gro_type_flag;
}
gro_ctx->gro_types = param->gro_types;
return gro_ctx;
}
void
rte_gro_ctx_destroy(void *ctx)
{
gro_tbl_destroy_fn destroy_tbl_fn;
struct gro_ctx *gro_ctx = ctx;
uint64_t gro_type_flag;
uint8_t i;
for (i = 0; i < RTE_GRO_TYPE_MAX_NUM; i++) {
gro: fix bitwise overflow When try to get GRO types, expression "1 << i" with type "int" may overflow. This patch is to fix this issue. Coverity issue: 158664 Fixes: e996506a1c07 ("lib/gro: add Generic Receive Offload API framework") Signed-off-by: Jiayu Hu <jiayu.hu@intel.com>
2017-07-31 01:43:24 +00:00
gro_type_flag = 1ULL << i;
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
if ((gro_ctx->gro_types & gro_type_flag) == 0)
continue;
destroy_tbl_fn = tbl_destroy_fn[i];
if (destroy_tbl_fn)
destroy_tbl_fn(gro_ctx->tbls[i]);
}
rte_free(gro_ctx);
}
uint16_t
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
rte_gro_reassemble_burst(struct rte_mbuf **pkts,
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
uint16_t nb_pkts,
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
const struct rte_gro_param *param)
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
{
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
/* allocate a reassembly table for TCP/IPv4 GRO */
struct gro_tcp4_tbl tcp_tbl;
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
struct gro_tcp4_flow tcp_flows[RTE_GRO_MAX_BURST_ITEM_NUM];
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
struct gro_tcp4_item tcp_items[RTE_GRO_MAX_BURST_ITEM_NUM] = {{0} };
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
/* allocate a reassembly table for UDP/IPv4 GRO */
struct gro_udp4_tbl udp_tbl;
struct gro_udp4_flow udp_flows[RTE_GRO_MAX_BURST_ITEM_NUM];
struct gro_udp4_item udp_items[RTE_GRO_MAX_BURST_ITEM_NUM] = {{0} };
/* Allocate a reassembly table for VXLAN TCP GRO */
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
struct gro_vxlan_tcp4_tbl vxlan_tcp_tbl;
struct gro_vxlan_tcp4_flow vxlan_tcp_flows[RTE_GRO_MAX_BURST_ITEM_NUM];
struct gro_vxlan_tcp4_item vxlan_tcp_items[RTE_GRO_MAX_BURST_ITEM_NUM]
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
= {{{0}, 0, 0} };
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
/* Allocate a reassembly table for VXLAN UDP GRO */
struct gro_vxlan_udp4_tbl vxlan_udp_tbl;
struct gro_vxlan_udp4_flow vxlan_udp_flows[RTE_GRO_MAX_BURST_ITEM_NUM];
struct gro_vxlan_udp4_item vxlan_udp_items[RTE_GRO_MAX_BURST_ITEM_NUM]
= {{{0}} };
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
struct rte_mbuf *unprocess_pkts[nb_pkts];
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
uint32_t item_num;
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
int32_t ret;
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
uint16_t i, unprocess_num = 0, nb_after_gro = nb_pkts;
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
uint8_t do_tcp4_gro = 0, do_vxlan_tcp_gro = 0, do_udp4_gro = 0,
do_vxlan_udp_gro = 0;
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
if (unlikely((param->gro_types & (RTE_GRO_IPV4_VXLAN_TCP_IPV4 |
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
RTE_GRO_TCP_IPV4 |
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
RTE_GRO_IPV4_VXLAN_UDP_IPV4 |
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
RTE_GRO_UDP_IPV4)) == 0))
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
return nb_pkts;
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
/* Get the maximum number of packets */
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
item_num = RTE_MIN(nb_pkts, (param->max_flow_num *
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
param->max_item_per_flow));
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
item_num = RTE_MIN(item_num, RTE_GRO_MAX_BURST_ITEM_NUM);
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
if (param->gro_types & RTE_GRO_IPV4_VXLAN_TCP_IPV4) {
for (i = 0; i < item_num; i++)
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
vxlan_tcp_flows[i].start_index = INVALID_ARRAY_INDEX;
vxlan_tcp_tbl.flows = vxlan_tcp_flows;
vxlan_tcp_tbl.items = vxlan_tcp_items;
vxlan_tcp_tbl.flow_num = 0;
vxlan_tcp_tbl.item_num = 0;
vxlan_tcp_tbl.max_flow_num = item_num;
vxlan_tcp_tbl.max_item_num = item_num;
do_vxlan_tcp_gro = 1;
}
if (param->gro_types & RTE_GRO_IPV4_VXLAN_UDP_IPV4) {
for (i = 0; i < item_num; i++)
vxlan_udp_flows[i].start_index = INVALID_ARRAY_INDEX;
vxlan_udp_tbl.flows = vxlan_udp_flows;
vxlan_udp_tbl.items = vxlan_udp_items;
vxlan_udp_tbl.flow_num = 0;
vxlan_udp_tbl.item_num = 0;
vxlan_udp_tbl.max_flow_num = item_num;
vxlan_udp_tbl.max_item_num = item_num;
do_vxlan_udp_gro = 1;
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
}
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
if (param->gro_types & RTE_GRO_TCP_IPV4) {
for (i = 0; i < item_num; i++)
tcp_flows[i].start_index = INVALID_ARRAY_INDEX;
tcp_tbl.flows = tcp_flows;
tcp_tbl.items = tcp_items;
tcp_tbl.flow_num = 0;
tcp_tbl.item_num = 0;
tcp_tbl.max_flow_num = item_num;
tcp_tbl.max_item_num = item_num;
do_tcp4_gro = 1;
}
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
if (param->gro_types & RTE_GRO_UDP_IPV4) {
for (i = 0; i < item_num; i++)
udp_flows[i].start_index = INVALID_ARRAY_INDEX;
udp_tbl.flows = udp_flows;
udp_tbl.items = udp_items;
udp_tbl.flow_num = 0;
udp_tbl.item_num = 0;
udp_tbl.max_flow_num = item_num;
udp_tbl.max_item_num = item_num;
do_udp4_gro = 1;
}
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
for (i = 0; i < nb_pkts; i++) {
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
/*
* The timestamp is ignored, since all packets
* will be flushed from the tables.
*/
if (IS_IPV4_VXLAN_TCP4_PKT(pkts[i]->packet_type) &&
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
do_vxlan_tcp_gro) {
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
ret = gro_vxlan_tcp4_reassemble(pkts[i],
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
&vxlan_tcp_tbl, 0);
if (ret > 0)
/* Merge successfully */
nb_after_gro--;
else if (ret < 0)
unprocess_pkts[unprocess_num++] = pkts[i];
} else if (IS_IPV4_VXLAN_UDP4_PKT(pkts[i]->packet_type) &&
do_vxlan_udp_gro) {
ret = gro_vxlan_udp4_reassemble(pkts[i],
&vxlan_udp_tbl, 0);
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
if (ret > 0)
/* Merge successfully */
nb_after_gro--;
else if (ret < 0)
unprocess_pkts[unprocess_num++] = pkts[i];
} else if (IS_IPV4_TCP_PKT(pkts[i]->packet_type) &&
do_tcp4_gro) {
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
ret = gro_tcp4_reassemble(pkts[i], &tcp_tbl, 0);
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
if (ret > 0)
/* merge successfully */
nb_after_gro--;
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
else if (ret < 0)
unprocess_pkts[unprocess_num++] = pkts[i];
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
} else if (IS_IPV4_UDP_PKT(pkts[i]->packet_type) &&
do_udp4_gro) {
ret = gro_udp4_reassemble(pkts[i], &udp_tbl, 0);
if (ret > 0)
/* merge successfully */
nb_after_gro--;
else if (ret < 0)
unprocess_pkts[unprocess_num++] = pkts[i];
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
} else
unprocess_pkts[unprocess_num++] = pkts[i];
}
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
if ((nb_after_gro < nb_pkts)
|| (unprocess_num < nb_pkts)) {
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
i = 0;
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
/* Flush all packets from the tables */
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
if (do_vxlan_tcp_gro) {
i = gro_vxlan_tcp4_tbl_timeout_flush(&vxlan_tcp_tbl,
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
0, pkts, nb_pkts);
}
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
if (do_vxlan_udp_gro) {
i += gro_vxlan_udp4_tbl_timeout_flush(&vxlan_udp_tbl,
0, &pkts[i], nb_pkts - i);
}
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
if (do_tcp4_gro) {
i += gro_tcp4_tbl_timeout_flush(&tcp_tbl, 0,
&pkts[i], nb_pkts - i);
}
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
if (do_udp4_gro) {
i += gro_udp4_tbl_timeout_flush(&udp_tbl, 0,
&pkts[i], nb_pkts - i);
}
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
/* Copy unprocessed packets */
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
if (unprocess_num > 0) {
memcpy(&pkts[i], unprocess_pkts,
sizeof(struct rte_mbuf *) *
unprocess_num);
}
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
nb_after_gro = i + unprocess_num;
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
}
return nb_after_gro;
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
}
uint16_t
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
rte_gro_reassemble(struct rte_mbuf **pkts,
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
uint16_t nb_pkts,
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
void *ctx)
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
{
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
struct rte_mbuf *unprocess_pkts[nb_pkts];
struct gro_ctx *gro_ctx = ctx;
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
void *tcp_tbl, *udp_tbl, *vxlan_tcp_tbl, *vxlan_udp_tbl;
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
uint64_t current_time;
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
uint16_t i, unprocess_num = 0;
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
uint8_t do_tcp4_gro, do_vxlan_tcp_gro, do_udp4_gro, do_vxlan_udp_gro;
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
if (unlikely((gro_ctx->gro_types & (RTE_GRO_IPV4_VXLAN_TCP_IPV4 |
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
RTE_GRO_TCP_IPV4 |
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
RTE_GRO_IPV4_VXLAN_UDP_IPV4 |
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
RTE_GRO_UDP_IPV4)) == 0))
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
return nb_pkts;
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
tcp_tbl = gro_ctx->tbls[RTE_GRO_TCP_IPV4_INDEX];
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
vxlan_tcp_tbl = gro_ctx->tbls[RTE_GRO_IPV4_VXLAN_TCP_IPV4_INDEX];
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
udp_tbl = gro_ctx->tbls[RTE_GRO_UDP_IPV4_INDEX];
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
vxlan_udp_tbl = gro_ctx->tbls[RTE_GRO_IPV4_VXLAN_UDP_IPV4_INDEX];
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
do_tcp4_gro = (gro_ctx->gro_types & RTE_GRO_TCP_IPV4) ==
RTE_GRO_TCP_IPV4;
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
do_vxlan_tcp_gro = (gro_ctx->gro_types & RTE_GRO_IPV4_VXLAN_TCP_IPV4) ==
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
RTE_GRO_IPV4_VXLAN_TCP_IPV4;
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
do_udp4_gro = (gro_ctx->gro_types & RTE_GRO_UDP_IPV4) ==
RTE_GRO_UDP_IPV4;
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
do_vxlan_udp_gro = (gro_ctx->gro_types & RTE_GRO_IPV4_VXLAN_UDP_IPV4) ==
RTE_GRO_IPV4_VXLAN_UDP_IPV4;
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
current_time = rte_rdtsc();
for (i = 0; i < nb_pkts; i++) {
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
if (IS_IPV4_VXLAN_TCP4_PKT(pkts[i]->packet_type) &&
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
do_vxlan_tcp_gro) {
if (gro_vxlan_tcp4_reassemble(pkts[i], vxlan_tcp_tbl,
current_time) < 0)
unprocess_pkts[unprocess_num++] = pkts[i];
} else if (IS_IPV4_VXLAN_UDP4_PKT(pkts[i]->packet_type) &&
do_vxlan_udp_gro) {
if (gro_vxlan_udp4_reassemble(pkts[i], vxlan_udp_tbl,
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
current_time) < 0)
unprocess_pkts[unprocess_num++] = pkts[i];
} else if (IS_IPV4_TCP_PKT(pkts[i]->packet_type) &&
do_tcp4_gro) {
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
if (gro_tcp4_reassemble(pkts[i], tcp_tbl,
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
current_time) < 0)
unprocess_pkts[unprocess_num++] = pkts[i];
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
} else if (IS_IPV4_UDP_PKT(pkts[i]->packet_type) &&
do_udp4_gro) {
if (gro_udp4_reassemble(pkts[i], udp_tbl,
current_time) < 0)
unprocess_pkts[unprocess_num++] = pkts[i];
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
} else
unprocess_pkts[unprocess_num++] = pkts[i];
}
if (unprocess_num > 0) {
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
memcpy(pkts, unprocess_pkts, sizeof(struct rte_mbuf *) *
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
unprocess_num);
}
return unprocess_num;
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
}
uint16_t
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
rte_gro_timeout_flush(void *ctx,
uint64_t timeout_cycles,
uint64_t gro_types,
struct rte_mbuf **out,
uint16_t max_nb_out)
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
{
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
struct gro_ctx *gro_ctx = ctx;
uint64_t flush_timestamp;
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
uint16_t num = 0;
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
uint16_t left_nb_out = max_nb_out;
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
gro_types = gro_types & gro_ctx->gro_types;
flush_timestamp = rte_rdtsc() - timeout_cycles;
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
if (gro_types & RTE_GRO_IPV4_VXLAN_TCP_IPV4) {
num = gro_vxlan_tcp4_tbl_timeout_flush(gro_ctx->tbls[
RTE_GRO_IPV4_VXLAN_TCP_IPV4_INDEX],
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
flush_timestamp, out, left_nb_out);
left_nb_out = max_nb_out - num;
gro: support VXLAN UDP/IPv4 VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble VXLAN UDP/IPv4 fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VXLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:39 +00:00
}
if ((gro_types & RTE_GRO_IPV4_VXLAN_UDP_IPV4) && left_nb_out > 0) {
num += gro_vxlan_udp4_tbl_timeout_flush(gro_ctx->tbls[
RTE_GRO_IPV4_VXLAN_UDP_IPV4_INDEX],
flush_timestamp, &out[num], left_nb_out);
left_nb_out = max_nb_out - num;
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
}
/* If no available space in 'out', stop flushing. */
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
if ((gro_types & RTE_GRO_TCP_IPV4) && left_nb_out > 0) {
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
num += gro_tcp4_tbl_timeout_flush(
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
gro_ctx->tbls[RTE_GRO_TCP_IPV4_INDEX],
flush_timestamp,
gro: support UDP/IPv4 UDP/IPv4 GRO can help improve VM-to-VM UDP performance when UFO or GSO is enabled in VM, GRO must be supported if UFO or GSO is enabled, otherwise, performance can't get big improvement if only GSO is there. With this enabled in DPDK, OVS DPDK can leverage it to improve VM-to-VM UDP performance, it will reassemble UDP fragments immediate after they are received from a physical NIC. It is very helpful in OVS DPDK VLAN use case. Signed-off-by: Yi Yang <yangyi01@inspur.com> Acked-by: Jiayu Hu <jiayu.hu@intel.com>
2020-09-24 08:57:38 +00:00
&out[num], left_nb_out);
left_nb_out = max_nb_out - num;
}
/* If no available space in 'out', stop flushing. */
if ((gro_types & RTE_GRO_UDP_IPV4) && left_nb_out > 0) {
num += gro_udp4_tbl_timeout_flush(
gro_ctx->tbls[RTE_GRO_UDP_IPV4_INDEX],
flush_timestamp,
&out[num], left_nb_out);
lib/gro: support TCP/IPv4 In this patch, we introduce five APIs to support TCP/IPv4 GRO. - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used to merge packets. - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 reassembly table. - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 reassembly table. TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP checksums for merged packets. If inputted packets are IP fragmented, TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 headers). In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly table, to reassemble packets. A TCP/IPv4 reassembly table includes a key array and a item array, where the key array keeps the criteria to merge packets and the item array keeps packet information. One key in the key array points to an item group, which consists of packets which have the same criteria value. If two packets are able to merge, they must be in the same item group. Each key in the key array includes two parts: - criteria: the criteria of merging packets. If two packets can be merged, they must have the same criteria value. - start_index: the index of the first incoming packet of the item group. Each element in the item array keeps the information of one packet. It mainly includes three parts: - firstseg: the address of the first segment of the packet - lastseg: the address of the last segment of the packet - next_pkt_index: the index of the next packet in the same item group. All packets in the same item group are chained by next_pkt_index. With next_pkt_index, we can locate all packets in the same item group one by one. To process an incoming packet needs three steps: a. check if the packet should be processed. Packets with one of the following properties won't be processed: - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; - packet payload length is 0. b. traverse the key array to find a key which has the same criteria value with the incoming packet. If find, goto step c. Otherwise, insert a new key and insert the packet into the item array. c. locate the first packet in the item group via the start_index in the key. Then traverse all packets in the item group via next_pkt_index. If find one packet which can merge with the incoming one, merge them together. If can't find, insert the packet into this item group. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:45 +00:00
}
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
gro: support VxLAN GRO This patch adds a framework that allows GRO on tunneled packets. Furthermore, it leverages that framework to provide GRO support for VxLAN-encapsulated packets. Supported VxLAN packets must have an outer IPv4 header, and contain an inner TCP/IPv4 packet. VxLAN GRO doesn't check if input packets have correct checksums and doesn't update checksums for output packets. Additionally, it assumes the packets are complete (i.e., MF==0 && frag_off==0), when IP fragmentation is possible (i.e., DF==0). Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com> Tested-by: Lei Yao <lei.a.yao@intel.com>
2018-01-10 14:03:12 +00:00
return num;
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
}
uint64_t
rte_gro_get_pkt_count(void *ctx)
{
struct gro_ctx *gro_ctx = ctx;
gro_tbl_pkt_count_fn pkt_count_fn;
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
uint64_t gro_types = gro_ctx->gro_types, flag;
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
uint64_t item_num = 0;
uint8_t i;
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
for (i = 0; i < RTE_GRO_TYPE_MAX_NUM && gro_types; i++) {
flag = 1ULL << i;
if ((gro_types & flag) == 0)
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
continue;
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
gro_types ^= flag;
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
pkt_count_fn = tbl_pkt_count_fn[i];
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
if (pkt_count_fn)
item_num += pkt_count_fn(gro_ctx->tbls[i]);
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
}
gro: cleanup This patch updates codes as follows: - change appropriate names for internal structures, variants and functions - update comments and the content of the gro programmer guide for better understanding - remove needless check and redundant comments Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Junjie Chen <junjie.j.chen@intel.com>
2018-01-10 14:03:10 +00:00
lib/gro: add Generic Receive Offload API framework Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overhead. It gains performance by reassembling small packets into large ones. This patchset is to support GRO in DPDK. To support GRO, this patch implements a GRO API framework. To enable more flexibility to applications, DPDK GRO is implemented as a user library. Applications explicitly use the GRO library to merge small packets into large ones. DPDK GRO provides two reassembly modes. One is called lightweight mode, the other is called heavyweight mode. If applications want to merge packets in a simple way and the number of packets is relatively small, they can use the lightweight mode. If applications need more fine-grained controls, they can choose the heavyweight mode. rte_gro_reassemble_burst is the main reassembly API which is used in lightweight mode and processes N packets at a time. For applications, performing GRO in lightweight mode is simple. They just need to invoke rte_gro_reassemble_burst. Applications can get GROed packets as soon as rte_gro_reassemble_burst returns. rte_gro_reassemble is the main reassembly API which is used in heavyweight mode and tries to merge N inputted packets with the packets in GRO reassembly tables. For applications, performing GRO in heavyweight mode is relatively complicated. Before performing GRO, applications need to create a GRO context object, which keeps reassembly tables of desired GRO types, by rte_gro_ctx_create. Then applications can use rte_gro_reassemble to merge packets. The GROed packets are in the reassembly tables of the GRO context object. If applications want to get them, applications need to manually flush them by flush API. Signed-off-by: Jiayu Hu <jiayu.hu@intel.com> Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 05:46:44 +00:00
return item_num;
}
Reference in New Issue Copy Permalink