tcp: Improve sender-sender and sender-receiver fairness on the same netisr
authorSepherosa Ziehau <sephe@dragonflybsd.org>
Thu, 17 Jan 2013 08:33:55 +0000 (16:33 +0800)
committerSepherosa Ziehau <sephe@dragonflybsd.org>
Tue, 22 Jan 2013 11:56:34 +0000 (19:56 +0800)
commit2fb3a851c77d952c5c8d64e64affd1c802adbc02
tree1749b08a96dc7dc6905ebfa94e00f3ec5a4038a8
parente41e61d527704e7aa16af8e67ac60563ee8e4962
tcp: Improve sender-sender and sender-receiver fairness on the same netisr

Yield to other senders or receivers on the same netisr if the current TCP
stream has sent certain amount of segments (currently 4) and is going to
burst more segments.  sysctl net.inet.tcp.fairsend could be used to tune
how many segements are allowed to burst.  For TSO capable devices, their
TSO aggregate size limit could also affect the number of segments allowed
to burst.  Set net.inet.tcp.fairsend to 0 will allow single TCP stream to
burst as much as it wants (the old TCP sender's behaviour).

"Fairsend" is performed at the places that do not affect segment sending
during congestion control:
- User requested output path
- ACK input path

Measured improvement in the following setup:

+---+            +---+
|   |<-----------| B |
|   |            +---+
| A |
|   |            +---+
|   |----------->| C |
+---+            +---+

A (i7-2600, w/ HT enabled), 82571EB
B (e3-1230, w/ HT enabled), 82574L
C (e3-1230, w/ HT enabled), 82574L
The performance stats are gathered from 'systat -if 1'

When A runs 8 TCP senders to C and 8 TCP receivers from B, sending
performance are same ~975Mbps, however, the receiving performance before
this commit stumbles between 670Mbps and 850Mbps; w/ "fairsend" receiving
performance stays at 981Mbps.

When A runs 16 TCP senders to C and 16 TCP receivers from B, sending
performance are same ~975Mbps, however, the receiving performance before
this commit goes from 960Mbps to 980Mbps; w/ "fairsend" receiving
performance stays at 981Mbps stably.

When there are more senders and receivers running on A, there is no
noticable performance difference on either sending or receiving between
non-"fairsend" and "fairsend", because senders are no longer being able
to do continuous large burst.

"Fairsend" also improves Jain's fairness index between various amount of
senders (8 ~ 128) a little bit (sending only tests).
sys/netinet/tcp_input.c
sys/netinet/tcp_output.c
sys/netinet/tcp_sack.c
sys/netinet/tcp_subr.c
sys/netinet/tcp_usrreq.c
sys/netinet/tcp_var.h