• Eric Dumazet's avatar
    tcp: try to send bigger TSO packets · 8ee602c6
    Eric Dumazet authored
    While investigating TCP performance, I found that TCP would
    sometimes send big skbs followed by a single MSS skb,
    in a 'locked' pattern.
    
    For instance, BIG TCP is enabled, MSS is set to have 4096 bytes
    of payload per segment. gso_max_size is set to 181000.
    
    This means that an optimal TCP packet size should contain
    44 * 4096 = 180224 bytes of payload,
    
    However, I was seeing packets sizes interleaved in this pattern:
    
    172032, 8192, 172032, 8192, 172032, 8192, <repeat>
    
    tcp_tso_should_defer() heuristic is defeated, because after a split of
    a packet in write queue for whatever reason (this might be a too small
    CWND or a small enough pacing_rate),
    the leftover packet in the queue is smaller than the optimal size.
    
    It is time to try to make 'leftover packets' bigger so that
    tcp_tso_should_defer() can give its full potential.
    
    After this patch, we can see the following output:
    
    14:13:34.009273 IP6 sender > receiver: Flags [P.], seq 4048380:4098360, ack 1, win 256, options [nop,nop,TS val 3425678144 ecr 1561784500], length 49980
    14:13:34.010272 IP6 sender > receiver: Flags [P.], seq 4098360:4148340, ack 1, win 256, options [nop,nop,TS val 3425678145 ecr 1561784501], length 49980
    14:13:34.011271 IP6 sender > receiver: Flags [P.], seq 4148340:4198320, ack 1, win 256, options [nop,nop,TS val 3425678146 ecr 1561784502], length 49980
    14:13:34.012271 IP6 sender > receiver: Flags [P.], seq 4198320:4248300, ack 1, win 256, options [nop,nop,TS val 3425678147 ecr 1561784503], length 49980
    14:13:34.013272 IP6 sender > receiver: Flags [P.], seq 4248300:4298280, ack 1, win 256, options [nop,nop,TS val 3425678148 ecr 1561784504], length 49980
    14:13:34.014271 IP6 sender > receiver: Flags [P.], seq 4298280:4348260, ack 1, win 256, options [nop,nop,TS val 3425678149 ecr 1561784505], length 49980
    14:13:34.015272 IP6 sender > receiver: Flags [P.], seq 4348260:4398240, ack 1, win 256, options [nop,nop,TS val 3425678150 ecr 1561784506], length 49980
    14:13:34.016270 IP6 sender > receiver: Flags [P.], seq 4398240:4448220, ack 1, win 256, options [nop,nop,TS val 3425678151 ecr 1561784507], length 49980
    14:13:34.017269 IP6 sender > receiver: Flags [P.], seq 4448220:4498200, ack 1, win 256, options [nop,nop,TS val 3425678152 ecr 1561784508], length 49980
    14:13:34.018276 IP6 sender > receiver: Flags [P.], seq 4498200:4548180, ack 1, win 256, options [nop,nop,TS val 3425678153 ecr 1561784509], length 49980
    14:13:34.019259 IP6 sender > receiver: Flags [P.], seq 4548180:4598160, ack 1, win 256, options [nop,nop,TS val 3425678154 ecr 1561784510], length 49980
    
    With 200 concurrent flows on a 100Gbit NIC, we can see a reduction
    of TSO packets (and ACK packets) of about 30 %.
    Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240418214600.1291486-4-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
    8ee602c6
tcp_output.c 129 KB