aboutsummaryrefslogtreecommitdiffstats
path: root/net/tipc/msg.h
diff options
context:
space:
mode:
authorTuong Lien <tuong.t.lien@dektech.com.au>2019-04-04 00:09:51 -0400
committerDavid S. Miller <davem@davemloft.net>2019-04-04 21:29:25 -0400
commit9195948fbf3406f75b1f133ddb57304169c44341 (patch)
tree73d17fca53e14c23642b1f844e12251fad333a61 /net/tipc/msg.h
parent29502bb127b14841f4fdab8898c851a4a83e136f (diff)
tipc: improve TIPC throughput by Gap ACK blocks
During unicast link transmission, it's observed very often that because of one or a few lost/dis-ordered packets, the sending side will fastly reach the send window limit and must wait for the packets to be arrived at the receiving side or in the worst case, a retransmission must be done first. The sending side cannot release a lot of subsequent packets in its transmq even though all of them might have already been received by the receiving side. That is, one or two packets dis-ordered/lost and dozens of packets have to wait, this obviously reduces the overall throughput! This commit introduces an algorithm to overcome this by using "Gap ACK blocks". Basically, a Gap ACK block will consist of <ack, gap> numbers that describes the link deferdq where packets have been got by the receiving side but with gaps, for example: link deferdq: [1 2 3 4 10 11 13 14 15 20] --> Gap ACK blocks: <4, 5>, <11, 1>, <15, 4>, <20, 0> The Gap ACK blocks will be sent to the sending side along with the traditional ACK or NACK message. Immediately when receiving the message the sending side will now not only release from its transmq the packets ack-ed by the ACK but also by the Gap ACK blocks! So, more packets can be enqueued and transmitted. In addition, the sending side can now do "multi-retransmissions" according to the Gaps reported in the Gap ACK blocks. The new algorithm as verified helps greatly improve the TIPC throughput especially under packet loss condition. So far, a maximum of 32 blocks is quite enough without any "Too few Gap ACK blocks" reports with a 5.0% packet loss rate, however this number can be increased in the furture if needed. Also, the patch is backward compatible. Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/tipc/msg.h')
-rw-r--r--net/tipc/msg.h31
1 files changed, 31 insertions, 0 deletions
diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index 528ba9241acc..ec5c511a9c9c 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -117,6 +117,37 @@ struct tipc_msg {
117 __be32 hdr[15]; 117 __be32 hdr[15];
118}; 118};
119 119
120/* struct tipc_gap_ack - TIPC Gap ACK block
121 * @ack: seqno of the last consecutive packet in link deferdq
122 * @gap: number of gap packets since the last ack
123 *
124 * E.g:
125 * link deferdq: 1 2 3 4 10 11 13 14 15 20
126 * --> Gap ACK blocks: <4, 5>, <11, 1>, <15, 4>, <20, 0>
127 */
128struct tipc_gap_ack {
129 __be16 ack;
130 __be16 gap;
131};
132
133/* struct tipc_gap_ack_blks
134 * @len: actual length of the record
135 * @gack_cnt: number of Gap ACK blocks in the record
136 * @gacks: array of Gap ACK blocks
137 */
138struct tipc_gap_ack_blks {
139 __be16 len;
140 u8 gack_cnt;
141 u8 reserved;
142 struct tipc_gap_ack gacks[];
143};
144
145#define tipc_gap_ack_blks_sz(n) (sizeof(struct tipc_gap_ack_blks) + \
146 sizeof(struct tipc_gap_ack) * (n))
147
148#define MAX_GAP_ACK_BLKS 32
149#define MAX_GAP_ACK_BLKS_SZ tipc_gap_ack_blks_sz(MAX_GAP_ACK_BLKS)
150
120static inline struct tipc_msg *buf_msg(struct sk_buff *skb) 151static inline struct tipc_msg *buf_msg(struct sk_buff *skb)
121{ 152{
122 return (struct tipc_msg *)skb->data; 153 return (struct tipc_msg *)skb->data;