The real device over which the rmnet devices are installed also
aggregate multiple IP packets and sends them as a single large
aggregate
frame to the hardware.
It would be nice to give some details about this in the changelog.
Also what results you get with different values for the shift (10, 9,
8)
My fear is that people might be tempted to blindly use the
sk_pacing_shift_update() just because a single TCP flow gets 'better'
results.
bufferbloat is a serious issue, we do not want to allow a single TCP
flow to fill a fifo.
Otherwise, we could remove TCP Small queues overhead from the kernel
and be happy.
Thanks.
The test was run with iperf single stream TCP TX for a duration of 30s.
Pacing shift | Observed data rate (Mbps)
10 | 9
9 | 140
8 | 146
I will update all of this in the commit text in v3.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
