But if the additional amount requested stays just below the
socket's memory limit, then the next skb won't have to wait, and
performance should be marginally better. I'm not sure whether this
will happen often enough to be worthwhile, but the extra code is
minimal, so it's worth a try.
I'm not putting this part of your changes in, the reason is simple.
More important than pushing out as much data as possible right now, is
using the link bandwidth as effectively as possible. This means using
full sized frames while more data is still pending. Sending off
tiny-grams is a problem and bad for overall performance.
Sending non-full frames can and will confuse critical TCP algorithms
at the receiver side, such as the ACK'ing policy. ACKs are the basis
for all feedback mechanisms used by TCP senders, for the purposes of
loss recovery and keeping the proper pace necessary to keep the link
at it's full capacity.
I will suggest another possible approach for further thought. You
could, at socket creation time, and also when getting sndbuf sockopt
setting requests, make the size of it a multiple of a full sized
frame. This also has two problems. First, skb->truesize is what is
added so you'd need to account for it. Secondly, this hack is then
TCP specific.
Nice idea, but doesn't work.
The patch also makes a minor change to sock_kmalloc, to decrement
the memory limit if the allocation fails.
This part is just fine, I'm putting it in.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu