DPDK patches and discussions
 help / color / mirror / Atom feed
From: 胡嘉瑜 <hujiayu.hu@foxmail.com>
To: Kumara Parameshwaran <kumaraparamesh92@gmail.com>, dev@dpdk.org
Cc: Kumara Parameshwaran <krathinavel@microsoft.com>
Subject: Re: [PATCH v9] gro: fix reordering of packets in GRO layer
Date: Thu, 4 Jan 2024 23:49:38 +0800	[thread overview]
Message-ID: <tencent_AF3BF7500AE00D66C0C1F0AD015A033B8105@qq.com> (raw)
In-Reply-To: <20231208181738.23931-1-kumaraparamesh92@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 7023 bytes --]


在 2023/12/9 上午2:17, Kumara Parameshwaran 写道:
> In the current implementation when a packet is received with
> special TCP flag(s) set, only that packet is delivered out of order.
> There could be already coalesced packets in the GRO table
> belonging to the same flow but not delivered.
> This fix makes sure that the entire segment is delivered with the
> special flag(s) set which is how the Linux GRO is also implemented
>
> Signed-off-by: Kumara Parameshwaran<kumaraparamesh92@gmail.com>
> Co-authored-by: Kumara Parameshwaran<krathinavel@microsoft.com>
> ---
> 	If the received packet is not a pure ACK packet, we check if
> 	there are any previous packets in the flow, if present we indulge
> 	the received packet also in the coalescing logic and update the flags
> 	of the last recived packet to the entire segment which would avoid
> 	re-ordering.
>
> 	Lets say a case where P1(PSH), P2(ACK), P3(ACK)  are received in burst mode,
> 	P1 contains PSH flag and since it does not contain any prior packets in the flow
> 	we copy it to unprocess_packets and P2(ACK) and P3(ACK) are merged together.
> 	In the existing case the  P2,P3 would be delivered as single segment first and the
> 	unprocess_packets will be copied later which will cause reordering. With the patch
> 	copy the unprocess packets first and then the packets from the GRO table.
>
> 	Testing done
> 	The csum test-pmd was modified to support the following
> 	GET request of 10MB from client to server via test-pmd (static arp entries added in client
> 	and server). Enable GRO and TSO in test-pmd where the packets recived from the client mac
> 	would be sent to server mac and vice versa.
> 	In above testing, without the patch the client observerd re-ordering of 25 packets
> 	and with the patch there were no packet re-ordering observerd.
>
> v2:
> 	Fix warnings in commit and comment.
> 	Do not consider packet as candidate to merge if it contains SYN/RST flag.
>
> v3:
> 	Fix warnings.
>
> v4:
> 	Rebase with master.
>
> v5:
> 	Adding co-author email
> v6:
> 	Address review comments from the maintainer to restructure the code
> 	and handle only special flags PSH,FIN
>
> v7:
> 	Fix warnings and errors
>
> v8:
> 	Fix warnings and errors
>
> v9:
> 	Fix commit message
>
>   lib/gro/gro_tcp.h  | 11 ++++++++
>   lib/gro/gro_tcp4.c | 67 +++++++++++++++++++++++++++++-----------------
>   2 files changed, 54 insertions(+), 24 deletions(-)
>
> diff --git a/lib/gro/gro_tcp.h b/lib/gro/gro_tcp.h
> index d926c4b8cc..137a03bc96 100644
> --- a/lib/gro/gro_tcp.h
> +++ b/lib/gro/gro_tcp.h
> @@ -187,4 +187,15 @@ is_same_common_tcp_key(struct cmn_tcp_key *k1, struct cmn_tcp_key *k2)
>   	return (!memcmp(k1, k2, sizeof(struct cmn_tcp_key)));
>   }
>   
> +static inline void
> +update_tcp_hdr_flags(struct rte_tcp_hdr *tcp_hdr, struct rte_mbuf *pkt)
> +{
> +	struct rte_tcp_hdr *merged_tcp_hdr;
> +
> +	merged_tcp_hdr = rte_pktmbuf_mtod_offset(pkt, struct rte_tcp_hdr *, pkt->l2_len +
> +							pkt->l3_len);
> +	merged_tcp_hdr->tcp_flags |= tcp_hdr->tcp_flags;
> +
> +}
> +
>   #endif
> diff --git a/lib/gro/gro_tcp4.c b/lib/gro/gro_tcp4.c
> index 6645de592b..8af5a8d8a9 100644
> --- a/lib/gro/gro_tcp4.c
> +++ b/lib/gro/gro_tcp4.c
> @@ -126,6 +126,7 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt,
>   	uint32_t item_idx;
>   	uint32_t i, max_flow_num, remaining_flow_num;
>   	uint8_t find;
> +	uint32_t item_start_idx;
>   
>   	/*
>   	 * Don't process the packet whose TCP header length is greater
> @@ -139,13 +140,6 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt,
>   	tcp_hdr = (struct rte_tcp_hdr *)((char *)ipv4_hdr + pkt->l3_len);
>   	hdr_len = pkt->l2_len + pkt->l3_len + pkt->l4_len;
>   
> -	/*
> -	 * Don't process the packet which has FIN, SYN, RST, PSH, URG, ECE
> -	 * or CWR set.
> -	 */
> -	if (tcp_hdr->tcp_flags != RTE_TCP_ACK_FLAG)
> -		return -1;
> -
>   	/* trim the tail padding bytes */
>   	ip_tlen = rte_be_to_cpu_16(ipv4_hdr->total_length);
>   	if (pkt->pkt_len > (uint32_t)(ip_tlen + pkt->l2_len))
> @@ -183,6 +177,7 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt,
>   		if (tbl->flows[i].start_index != INVALID_ARRAY_INDEX) {
>   			if (is_same_tcp4_flow(tbl->flows[i].key, key)) {
>   				find = 1;
> +				item_start_idx = tbl->flows[i].start_index;
>   				break;
>   			}
>   			remaining_flow_num--;
> @@ -190,28 +185,52 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt,
>   	}
>   
>   	if (find == 0) {

It is more likely to find a match flow. So better to put the below logic 
to the else statement.

> -		sent_seq = rte_be_to_cpu_32(tcp_hdr->sent_seq);
> -		item_idx = insert_new_tcp_item(pkt, tbl->items, &tbl->item_num,
> -						tbl->max_item_num, start_time,
> -						INVALID_ARRAY_INDEX, sent_seq, ip_id,
> -						is_atomic);
> -		if (item_idx == INVALID_ARRAY_INDEX)
> +		/*
> +		 * Add new flow to the table only if contains ACK flag with data.
> +		 * Do not add any packets with additional tcp flags to the GRO table
> +		 */
> +		if (tcp_hdr->tcp_flags == RTE_TCP_ACK_FLAG) {
> +			sent_seq = rte_be_to_cpu_32(tcp_hdr->sent_seq);
> +			item_idx = insert_new_tcp_item(pkt, tbl->items, &tbl->item_num,
> +							tbl->max_item_num, start_time,
> +							INVALID_ARRAY_INDEX, sent_seq, ip_id,
> +							is_atomic);
> +			if (item_idx == INVALID_ARRAY_INDEX)
> +				return -1;
> +			if (insert_new_flow(tbl, &key, item_idx) ==
> +				INVALID_ARRAY_INDEX) {
> +				/*
> +				 * Fail to insert a new flow, so delete the
> +				 * stored packet.
> +				 */
> +				delete_tcp_item(tbl->items, item_idx, &tbl->item_num,
> +					INVALID_ARRAY_INDEX);
> +				return -1;
> +			}
> +			return 0;
> +		} else {

"else" is not needed.

>   			return -1;
> -		if (insert_new_flow(tbl, &key, item_idx) ==
> -			INVALID_ARRAY_INDEX) {
> -			/*
> -			 * Fail to insert a new flow, so delete the
> -			 * stored packet.
> -			*/
> -			delete_tcp_item(tbl->items, item_idx, &tbl->item_num, INVALID_ARRAY_INDEX);
> +		}
> +	} else {
> +		/*
> +		 * Any packet with additional flags like PSH,FIN should be processed
> +		 * and flushed immediately.
> +		 * Hence marking the start time to 0, so that the packets will be flushed
> +		 * immediately in timer mode.
> +		 */
> +		if (tcp_hdr->tcp_flags & (RTE_TCP_ACK_FLAG|RTE_TCP_PSH_FLAG|RTE_TCP_FIN_FLAG)) {
Add a space beween RTE_TCP_ACK_FLAG and '|'.
> +			if (tcp_hdr->tcp_flags != RTE_TCP_ACK_FLAG)
> +				tbl->items[item_start_idx].start_time = 0;
> +			return process_tcp_item(pkt, tcp_hdr, tcp_dl, tbl->items,
> +						tbl->flows[i].start_index,
> +						&tbl->item_num, tbl->max_item_num,
> +						ip_id, is_atomic, start_time);
> +		} else {

It is better to check the "invalid" flags, like SYN, RST and URG, at the 
beginning of

gro_tcp4_reassemble(), as the packet can be returned earlier.

Thanks,

Jiayu

>   			return -1;
>   		}
> -		return 0;
>   	}
>   
> -	return process_tcp_item(pkt, tcp_hdr, tcp_dl, tbl->items, tbl->flows[i].start_index,
> -						&tbl->item_num, tbl->max_item_num,
> -						ip_id, is_atomic, start_time);
> +	return -1;
>   }
>   
>   /*

[-- Attachment #2: Type: text/html, Size: 8305 bytes --]

  reply	other threads:[~2024-01-04 15:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-13 10:18 [PATCH] gro : fix reordering of packets in GRO library Kumara Parameshwaran
2022-10-13 10:20 ` kumaraparameshwaran rathinavel
2022-10-28  8:09 ` [PATCH v2] " Kumara Parameshwaran
2022-10-28  8:27 ` [PATCH v3] " Kumara Parameshwaran
2022-10-28  9:51 ` [PATCH v4] " Kumara Parameshwaran
2022-11-01  7:05   ` [PATCH v5] " Kumara Parameshwaran
2023-06-19 13:25     ` Thomas Monjalon
2023-06-20  7:35     ` Hu, Jiayu
2023-06-21  8:47       ` kumaraparameshwaran rathinavel
2023-06-30 11:32       ` kumaraparameshwaran rathinavel
2023-12-08 17:54     ` [PATCH v6] gro: fix reordering of packets in GRO layer Kumara Parameshwaran
2023-12-08 18:05     ` [PATCH v7] " Kumara Parameshwaran
2023-12-08 18:12     ` [PATCH v8] " Kumara Parameshwaran
2023-12-08 18:17     ` [PATCH v9] " Kumara Parameshwaran
2024-01-04 15:49       ` 胡嘉瑜 [this message]
2024-01-07 11:21       ` [PATCH v10] " Kumara Parameshwaran
2024-01-07 11:29       ` [PATCH v11] " Kumara Parameshwaran
2024-01-07 17:20         ` Stephen Hemminger
2024-01-08 16:11           ` kumaraparameshwaran rathinavel
2024-01-08 15:50       ` [PATCH v12] " Kumara Parameshwaran
2024-01-08 16:04       ` [PATCH v13] " Kumara Parameshwaran
2024-01-16 14:28         ` 胡嘉瑜
2024-02-12 14:30           ` Thomas Monjalon
     [not found] <20240117195228.423261-1-kumaraparamesh92@gmail.co>
2024-01-17 20:10 ` [PATCH v9] " Kumara Parameshwaran
2024-01-17 20:13   ` kumaraparameshwaran rathinavel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tencent_AF3BF7500AE00D66C0C1F0AD015A033B8105@qq.com \
    --to=hujiayu.hu@foxmail.com \
    --cc=dev@dpdk.org \
    --cc=krathinavel@microsoft.com \
    --cc=kumaraparamesh92@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).