|
@@ -211,41 +211,30 @@ struct tcp_mss_option {
|
211
|
211
|
#define MIN_PKB_LEN MAX_HDR_LEN + 100 /* To account for padding by LL */
|
212
|
212
|
|
213
|
213
|
/**
|
214
|
|
- * Advertised TCP window size
|
|
214
|
+ * Maxmimum advertised TCP window size
|
215
|
215
|
*
|
216
|
|
- *
|
217
|
|
- * Our TCP window is actually limited by the amount of space available
|
218
|
|
- * for RX packets in the NIC's RX ring; we tend to populate the rings
|
219
|
|
- * with far fewer descriptors than a typical driver. This would
|
220
|
|
- * result in a desperately small window size, which kills WAN download
|
221
|
|
- * performance; the maximum bandwidth on any link is limited to
|
222
|
|
- *
|
223
|
|
- * max_bandwidth = ( tcp_window / round_trip_time )
|
224
|
|
- *
|
225
|
|
- * With a 4kB window, which probably accurately reflects our amount of
|
226
|
|
- * buffer space, and a WAN RTT of say 200ms, this gives a maximum
|
227
|
|
- * achievable bandwidth of 20kB/s, which is not acceptable.
|
228
|
|
- *
|
229
|
|
- * We therefore aim to process packets as fast as they arrive, and
|
230
|
|
- * advertise an "infinite" window. If we don't process packets as
|
231
|
|
- * fast as they arrive, then we will drop packets and have to incur
|
232
|
|
- * the retransmission penalty.
|
|
216
|
+ * We estimate the TCP window size as the amount of free memory we
|
|
217
|
+ * have. This is not strictly accurate (since it ignores any space
|
|
218
|
+ * already allocated as RX buffers), but it will do for now.
|
233
|
219
|
*
|
234
|
220
|
* Since we don't store out-of-order received packets, the
|
235
|
221
|
* retransmission penalty is that the whole window contents must be
|
236
|
|
- * resent.
|
|
222
|
+ * resent. This suggests keeping the window size small, but bear in
|
|
223
|
+ * mind that the maximum bandwidth on any link is limited to
|
|
224
|
+ *
|
|
225
|
+ * max_bandwidth = ( tcp_window / round_trip_time )
|
237
|
226
|
*
|
238
|
|
- * We choose to compromise on a window size of 64kB (which is the
|
239
|
|
- * maximum that can be represented without using TCP options). This
|
240
|
|
- * gives a maximum bandwidth of 320kB/s at 200ms RTT, which is
|
241
|
|
- * probably faster than the actual link bandwidth. It also limits
|
242
|
|
- * retransmissions to 64kB, which is reasonable.
|
|
227
|
+ * With a 48kB window, which probably accurately reflects our amount
|
|
228
|
+ * of free memory, and a WAN RTT of say 200ms, this gives a maximum
|
|
229
|
+ * bandwidth of 240kB/s. This is sufficiently close to realistic that
|
|
230
|
+ * we will need to be careful that our advertised window doesn't end
|
|
231
|
+ * up limiting WAN download speeds.
|
243
|
232
|
*
|
244
|
233
|
* Finally, since the window goes into a 16-bit field and we cannot
|
245
|
234
|
* actually use 65536, we use a window size of (65536-4) to ensure
|
246
|
235
|
* that payloads remain dword-aligned.
|
247
|
236
|
*/
|
248
|
|
-#define TCP_WINDOW_SIZE ( 65536 - 4 )
|
|
237
|
+#define TCP_MAX_WINDOW_SIZE ( 65536 - 4 )
|
249
|
238
|
|
250
|
239
|
/**
|
251
|
240
|
* Advertised TCP MSS
|